WikiLabs - Contribuții utilizator [ro]

OS Lab 11 - Linux Kernel Modules

2025-12-19T14:46:53Z

Vserbu: Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Explain the kernel module lifecycle and how loadable modules extend kernel func...

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the kernel module lifecycle and how loadable modules extend kernel functionality without requiring a reboot or kernel recompilation.
* Understand the miscdevice framework for creating character devices that appear in <code>/dev/</code> and respond to file operations.
* Implement proper kernel-space buffer management with mutex-based synchronization to handle concurrent access safely.
* Use the ioctl() interface to pass configuration structures between userspace and kernel space, enabling device-specific operations beyond standard read/write.
* Apply safe data transfer techniques using copy_to_user() and copy_from_user() to respect memory protection boundaries.
* Implement byte transformations (case conversion, character filtering) that execute in kernel context during write operations.
* Debug kernel code using printk() and interpret kernel log messages to diagnose issues.
* Connect kernel programming concepts to previous labs: device files (Lab 2), system calls (Lab 3), IPC mechanisms (Lab 6), and kernel primitives (Labs 7-10).


== Introduction ==


=== What You'll Build: The Superpipe Device ===

You'll implement a loadable kernel module called '''superpipe''' that creates a character device at <code>/dev/superpipe</code>. This device acts like a regular pipe with a twist: it can transform data as it passes through.

'''How it works:'''

# Userspace writes data to <code>/dev/superpipe</code> (normal <code>write()</code> syscall)
# Your kernel module receives the data, applies a transformation (uppercase, lowercase, filter vowels, etc.), and stores it in a kernel buffer
# Userspace reads data from <code>/dev/superpipe</code> (normal <code>read()</code> syscall)
# Your kernel module returns the transformed data
# Userspace configures the transformation mode using <code>ioctl()</code> (passing configuration structures)

'''Example usage:'''

<syntaxhighlight lang="bash"># Set transformation to uppercase via ioctl
./test_superpipe set_mode upper

# Write lowercase text
echo "hello world" > /dev/superpipe

# Read back - gets uppercase version
cat /dev/superpipe
# Output: HELLO WORLD</syntaxhighlight>
This demonstrates core kernel programming concepts:

* '''Device registration:''' Creating a device file that appears in <code>/dev/</code>
* '''File operations:''' Implementing the kernel side of open, read, write, close
* '''Memory management:''' Allocating kernel buffers with <code>kmalloc()</code>, using <code>kfree()</code>
* '''Data transfer:''' Safely moving data between user and kernel space
* '''Synchronization:''' Using mutexes to protect shared data from concurrent access
* '''ioctl interface:''' Passing configuration structures for device-specific operations
* '''Transform-on-write:''' Applying byte transformations as data enters the kernel


== Prerequisites ==


=== System Requirements ===

'''Operating System:''' Linux-based system with kernel 5.x or 6.x

Check your kernel version:

<syntaxhighlight lang="bash">uname -r</syntaxhighlight>
If you're running kernel 4.x or older, you may encounter compatibility issues with some kernel APIs used in this lab.

'''Kernel Headers:''' You must have kernel headers installed that match your running kernel. The headers provide the necessary definitions and build infrastructure for compiling kernel modules.

'''Build Tools:''' GCC compiler and make utility for building the module.

'''Privileges:''' Root access via <code>sudo</code> is required for loading/unloading modules and accessing device files.

'''Disk Space:''' At least 500MB free for kernel headers and build artifacts.

'''IMPORTANT: Work in a Virtual Machine'''

Kernel programming is different from userspace programming. Bugs in kernel code can cause kernel panics, system freezes, or data corruption. A simple null pointer dereference that would segfault in userspace can crash your entire system in kernel space.

Therefore, it is '''strongly recommended''' to work in a virtual machine (VirtualBox, VMware, QEMU, or similar). This way, if your module crashes the kernel, you can simply restart the VM without affecting your host system.


=== Required Packages ===

Install the necessary packages:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
build-essential \
linux-headers-$(uname -r) \
vim</syntaxhighlight>
'''Package descriptions:'''

* <code>build-essential</code>: Meta-package that installs GCC, make, and other compilation tools
* <code>linux-headers-$(uname -r)</code>: Kernel header files matching your running kernel version
* <code>vim</code>: Text editor (or use your preferred editor)

'''Verify kernel headers installation:'''

<syntaxhighlight lang="bash">ls -l /lib/modules/$(uname -r)/build</syntaxhighlight>
This should show a symbolic link pointing to the kernel build directory (usually in <code>/usr/src/</code>). If this directory doesn't exist, your kernel headers are not properly installed.


== Theoretical Background ==


=== Kernel Modules: Extending the Kernel Dynamically ===


==== What is a Kernel Module? ====

The Linux kernel is the core of the operating system—it manages hardware, enforces security, schedules processes, and provides the abstractions (files, processes, sockets) that userspace programs rely on. But the kernel faces a design challenge: it must support thousands of different hardware devices, filesystems, network protocols, and features. If every possible driver and feature were compiled directly into the kernel, the kernel image would be enormous, and systems would waste memory loading features they never use.

Linux solves this with '''loadable kernel modules'''—pieces of code that can be dynamically loaded into the running kernel and unloaded when no longer needed. Think of modules as plugins for the kernel.

'''Benefits of kernel modules:'''

# '''Flexibility:''' Load only the drivers and features you actually need
# '''Development speed:''' Test kernel code without rebooting
# '''Modularity:''' Separate concerns (network drivers, filesystem support, etc.) into independent modules
# '''Distribution:''' Ship proprietary drivers separately from the GPL-licensed kernel
# '''Memory efficiency:''' Don't waste RAM on unused features

'''Examples of kernel modules:'''

<syntaxhighlight lang="bash">lsmod</syntaxhighlight>
This command lists currently loaded modules. You'll see entries like:

* <code>nvidia</code> - NVIDIA graphics driver
* <code>ext4</code> - ext4 filesystem support
* <code>iwlwifi</code> - Intel wireless driver
* <code>bluetooth</code> - Bluetooth protocol support

Each of these started as a <code>.ko</code> file (kernel object) on disk and was loaded into the running kernel.


==== Module Lifecycle ====

A kernel module progresses through a well-defined lifecycle:

<pre>┌─────────────────────┐
│ Module Source │ module.c (your code)
│ (.c file) │
└──────────┬──────────┘
│ Compilation (make)
↓
┌─────────────────────┐
│ Module Binary │ module.ko (kernel object)
│ (.ko file) │ Lives on disk
└──────────┬──────────┘
│ insmod / modprobe
↓
┌─────────────────────┐
│ Init Function │ module_init() runs
│ Runs Once │ Allocates resources
│ │ Registers device
└──────────┬──────────┘
│ Success
↓
┌─────────────────────┐
│ Module Loaded │ Module is active
│ Functions Callable│ Handlers installed
│ │ Device available
└──────────┬──────────┘
│ rmmod
↓
┌─────────────────────┐
│ Exit Function │ module_exit() runs
│ Runs Once │ Frees resources
│ │ Unregisters device
└─────────────────────┘</pre>
'''Key commands:'''

* '''insmod''': Insert module (basic loader, requires full path)
* '''rmmod''': Remove module (must not be in use)
* '''lsmod''': List loaded modules
* '''modprobe''': Smart loader (resolves dependencies, searches standard paths)
* '''modinfo''': Display module information

'''Example:'''

<syntaxhighlight lang="bash"># Compile module
make

# Load module
sudo insmod superpipe.ko

# Verify loaded
lsmod | grep superpipe

# View module info
modinfo superpipe.ko

# Unload module
sudo rmmod superpipe</syntaxhighlight>

==== Kernel Space vs. User Space ====

Modern operating systems divide memory into two distinct regions with different privilege levels:

'''User Space:'''

* Where normal applications run
* Limited privileges
* Cannot access hardware directly
* Cannot access other processes' memory
* Errors cause process to crash (segmentation fault), not system crash

'''Kernel Space:'''

* Where kernel code runs (including your module!)
* Full privileges (can access all memory, all hardware)
* Can execute privileged CPU instructions
* Errors can crash the entire system (kernel panic)

<pre>┌─────────────────────────────────────────────┐
│ User Space │
│ │
│ [Process 1] [Process 2] [Process 3] ... │
│ │
│ Limited privileges │
│ Protected memory │
│ Crash = segfault (only that process dies) │
│ │
└─────────────────┬───────────────────────────┘
│ System Call Interface
│ (open, read, write, ioctl, ...)
┌─────────────────▼───────────────────────────┐
│ Kernel Space │
│ │
│ [Kernel Core] [Your Module] [Drivers] ... │
│ │
│ Full privileges │
│ Access to all memory │
│ Crash = kernel panic (entire system down) │
│ │
└─────────────────────────────────────────────┘</pre>
'''Critical differences for kernel programming:'''

{| class="wikitable"
|-
! Aspect
! User Space
! Kernel Space
|-
| Memory allocation
| <code>malloc()</code>, <code>free()</code>
| <code>kmalloc()</code>, <code>kfree()</code>
|-
| Printing
| <code>printf()</code>
| <code>printk()</code>
|-
| Standard library
| Full libc available
| '''No libc!''' Only kernel functions
|-
| Floating point
| Allowed
| '''Forbidden''' (saves/restores FPU state manually)
|-
| Sleep/wait
| Can block freely
| Must use special functions
|-
| Error handling
| Program crashes
| System crashes
|}

'''Why these restrictions?'''

The kernel is responsible for managing all system resources and mediating between competing processes. It cannot rely on any userspace code or libraries because it IS the foundation that everything else relies on. Additionally, the kernel must be extremely efficient—it gets invoked millions of times per second.


=== Character Devices and the Miscdevice Framework ===


==== Device Files in /dev/ ====

In Unix philosophy, "everything is a file." This includes hardware devices. The <code>/dev/</code> directory contains special files that represent devices—when you read from or write to these files, you're actually communicating with hardware or kernel drivers.

'''Examine your system:'''

<syntaxhighlight lang="bash">ls -l /dev/</syntaxhighlight>
You'll see entries like:

<pre>crw-rw-rw- 1 root root 1, 3 Dec 19 10:00 null
crw-rw-rw- 1 root root 1, 5 Dec 19 10:00 zero
crw-rw-rw- 1 root root 1, 8 Dec 19 10:00 random
crw-rw-rw- 1 root root 1, 9 Dec 19 10:00 urandom
brw-rw---- 1 root disk 8, 0 Dec 19 10:00 sda
crw------- 1 root root 10, 58 Dec 19 10:00 hw_random</pre>
'''Decoding the first character:'''

* <code>c</code> = character device
* <code>b</code> = block device
* <code>l</code> = symbolic link
* <code>d</code> = directory


==== Character Devices vs. Block Devices ====

'''Character devices''' (c):

* Data accessed as a stream of bytes
* No random access (typically)
* Examples: serial ports (<code>/dev/ttyS0</code>), terminals (<code>/dev/tty</code>), random number generator (<code>/dev/random</code>)
* Used for devices where data flows sequentially

'''Block devices''' (b):

* Data accessed in fixed-size blocks (typically 512 bytes, 1kB or 4kB)
* Random access supported
* Examples: solid-state drives (<code>/dev/nvme0n1</code>), hard drives (<code>/dev/sda</code>), USB drives (<code>/dev/sdb</code>), loop devices
* Used for storage devices with addressable blocks

Our superpipe device is a '''character device''' because it operates on byte streams without random access.


==== Major and Minor Numbers ====

Every device file has two numbers associated with it:

<pre>crw-rw-rw- 1 root root 1, 3 Dec 19 10:00 null
↑ ↑
Major Minor</pre>
'''Major number:''' Identifies the driver

* The kernel uses this to route operations to the correct driver
* Example: Major 1 = memory devices (<code>/dev/null</code>, <code>/dev/zero</code>, <code>/dev/random</code>)
* Example: Major 8 = SCSI disk devices (<code>/dev/sda</code>, <code>/dev/sdb</code>)

'''Minor number:''' Identifies specific device instance within that driver

* Interpreted by the driver, not the kernel
* Example: <code>/dev/sda</code> (8,0), <code>/dev/sda1</code> (8,1), <code>/dev/sda2</code> (8,2)
* The SCSI driver uses minor number to distinguish between disks and partitions


==== The Miscdevice Framework ====

Creating a character device traditionally requires:

# Registering a major number with <code>register_chrdev()</code>
# Implementing a full character device structure
# Handling device creation in <code>/dev/</code> (or relying on udev)

This is tedious for simple devices. The '''miscdevice''' framework simplifies this:

'''Benefits:'''

* '''Automatic major number:''' All miscdevices share major number 10
* '''Dynamic minor allocation:''' Kernel assigns minor numbers automatically
* '''Simplified registration:''' Single function call to register
* '''Automatic /dev/ creation:''' Device appears automatically when registered

'''Perfect for:'''

* Simple character devices
* Pseudo-devices (devices not tied to hardware)
* Control interfaces

'''The miscdevice structure:'''

<syntaxhighlight lang="c">#include <linux/miscdevice.h>

struct miscdevice {
int minor; /* Minor number (or MISC_DYNAMIC_MINOR) */
const char *name; /* Device name (creates /dev/<name>) */
const struct file_operations *fops; /* File operations */
/* ... other fields ... */
};</syntaxhighlight>
'''Using miscdevice:'''

<syntaxhighlight lang="c">static struct miscdevice my_device = {
.minor = MISC_DYNAMIC_MINOR, /* Kernel assigns minor number */
.name = "mydevice", /* Creates /dev/mydevice */
.fops = &my_fops, /* Your file operations */
};

/* In module init */
misc_register(&my_device); /* Register device */

/* In module exit */
misc_deregister(&my_device); /* Unregister device */</syntaxhighlight>
That's it! The device appears in <code>/dev/mydevice</code> and is ready to use.


=== File Operations: The Kernel Side of System Calls ===


==== The file_operations Structure ====

When userspace makes system calls like <code>open()</code>, <code>read()</code>, or <code>write()</code> on your device file, the kernel needs to know which functions in your module to call. This mapping is provided by the <code>file_operations</code> structure.

'''The structure (simplified):'''

<syntaxhighlight lang="c">#include <linux/fs.h>

struct file_operations {
struct module *owner; /* Pointer to module (prevents unload while in use) */

/* Open/close */
int (*open)(struct inode *, struct file *);
int (*release)(struct inode *, struct file *);

/* Read/write */
ssize_t (*read)(struct file *, char __user *, size_t, loff_t *);
ssize_t (*write)(struct file *, const char __user *, size_t, loff_t *);

/* ioctl */
long (*unlocked_ioctl)(struct file *, unsigned int, unsigned long);

/* ... many more operations (lseek, poll, mmap, etc.) ... */
};</syntaxhighlight>
'''Example:'''

<syntaxhighlight lang="c">static const struct file_operations my_fops = {
.owner = THIS_MODULE,
.open = my_open,
.release = my_release,
.read = my_read,
.write = my_write,
.unlocked_ioctl = my_ioctl,
};</syntaxhighlight>
You implement only the operations your device supports. Operations you don't implement default to appropriate behavior (typically returning -EINVAL or -ENOSYS).


==== Understanding the Handlers ====

'''open handler:'''

Called when userspace opens your device file.

<syntaxhighlight lang="c">static int my_open(struct inode *inode, struct file *file)
{
/* Allocate per-file state, increment usage counters, etc. */
printk(KERN_INFO "Device opened\n");
return 0; /* Success */
}</syntaxhighlight>
'''Parameters:'''

* <code>inode</code>: Represents the device file on disk (contains major/minor numbers)
* <code>file</code>: Represents an open file descriptor (contains file offset, flags, private_data)

'''release handler:'''

Called when userspace closes your device file.

<syntaxhighlight lang="c">static int my_release(struct inode *inode, struct file *file)
{
/* Free resources, decrement counters, etc. */
printk(KERN_INFO "Device closed\n");
return 0;
}</syntaxhighlight>
'''Note:''' Called "release" not "close" because multiple file descriptors can point to the same open file (via <code>dup()</code> or <code>fork()</code>). Release is called when the last reference is closed.

'''read handler:'''

Called when userspace reads from your device.

<syntaxhighlight lang="c">static ssize_t my_read(struct file *file, char __user *buffer,
size_t count, loff_t *offset)
{
/* Copy data from kernel space to userspace buffer */
/* Return number of bytes read, 0 for EOF, negative for error */
}</syntaxhighlight>
'''Parameters:'''

* <code>file</code>: The open file
* <code>buffer</code>: '''Userspace''' buffer (marked with <code>__user</code> annotation)
* <code>count</code>: Number of bytes requested
* <code>offset</code>: File offset (can be updated)

'''Return value:'''

* Positive: Number of bytes successfully read
* 0: End of file
* Negative: Error code

'''write handler:'''

Called when userspace writes to your device.

<syntaxhighlight lang="c">static ssize_t my_write(struct file *file, const char __user *buffer,
size_t count, loff_t *offset)
{
/* Copy data from userspace buffer to kernel space */
/* Return number of bytes written, negative for error */
}</syntaxhighlight>
'''unlocked_ioctl handler:'''

Called when userspace invokes ioctl() for device-specific operations.

<syntaxhighlight lang="c">static long my_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
/* Handle device-specific commands */
/* 'arg' can be a value or a pointer to userspace memory */
}</syntaxhighlight>
We'll explore ioctl in detail in section 4.6.


=== Moving Data Between Kernel and User Space ===


==== Why We Can't Access User Memory Directly ====

This is one of the most critical concepts in kernel programming and a common source of bugs for beginners.

'''The problem:'''

In userspace, when you have a pointer, you can just dereference it:

<syntaxhighlight lang="c">char *str = "hello";
printf("%c", str[0]); /* Works fine in userspace */</syntaxhighlight>
In kernel space, you '''cannot''' do this with pointers to userspace memory:

<syntaxhighlight lang="c">/* WRONG - will crash the kernel! */
static ssize_t my_read(struct file *file, char __user *user_buffer, ...)
{
user_buffer[0] = 'A'; /* NEVER DO THIS! */
strcpy(user_buffer, kernel_data); /* NEVER DO THIS! */
}</syntaxhighlight>
'''Why not?'''

# '''Memory protection:''' User memory might not be mapped, might be swapped to disk, or might not exist at all (bad pointer)
# '''Page faults:''' Accessing user memory can cause page faults, which need special handling in kernel context
# '''Security:''' The kernel must validate that the user actually has permission to access that memory
# '''MMU (Memory Management Unit):''' The CPU's MMU enforces that kernel code cannot directly access user address space

'''What happens if you try?'''

In the best case, you get a kernel oops (non-fatal kernel error). In the worst case, you corrupt memory and cause a kernel panic (crash).


==== The Safe Way: copy_to_user and copy_from_user ====

The kernel provides safe functions for transferring data between kernel and user space:

'''copy_to_user:''' Copy from kernel to userspace

<syntaxhighlight lang="c">#include <linux/uaccess.h>

unsigned long copy_to_user(void __user *to, const void *from, unsigned long n);</syntaxhighlight>
'''Parameters:'''

* <code>to</code>: Destination in userspace (marked with <code>__user</code>)
* <code>from</code>: Source in kernel space
* <code>n</code>: Number of bytes to copy

'''Return value:'''

* 0: Success (all bytes copied)
* Non-zero: Number of bytes that could NOT be copied (failure)

'''Example:'''

<syntaxhighlight lang="c">char kernel_buffer[100] = "Hello from kernel";

if (copy_to_user(user_buffer, kernel_buffer, strlen(kernel_buffer))) {
return -EFAULT; /* Bad address - tell userspace */
}</syntaxhighlight>
'''copy_from_user:''' Copy from userspace to kernel

<syntaxhighlight lang="c">unsigned long copy_from_user(void *to, const void __user *from, unsigned long n);</syntaxhighlight>
'''Parameters:'''

* <code>to</code>: Destination in kernel space
* <code>from</code>: Source in userspace (marked with <code>__user</code>)
* <code>n</code>: Number of bytes to copy

'''Return value:'''

* 0: Success
* Non-zero: Number of bytes that could NOT be copied

'''Example:'''

<syntaxhighlight lang="c">char kernel_buffer[100];

if (copy_from_user(kernel_buffer, user_buffer, count)) {
return -EFAULT; /* Bad address */
}</syntaxhighlight>
'''What these functions do:'''

# Check that the user address is valid
# Check that the user has permission to access that memory
# Handle page faults if the memory is swapped out
# Actually perform the copy
# Return success/failure

'''The __user annotation:'''

The <code>__user</code> marker is a sparse (static analysis tool) annotation that helps catch bugs at compile time. It doesn't affect the generated code, but it helps ensure you're using the right functions.


==== Error Codes: Communicating Failures ====

When something goes wrong in your kernel module, you communicate this to userspace by returning negative error codes.

'''Common error codes:'''

{| class="wikitable"
|-
! Error Code
! Value
! Meaning
! When to use
|-
| <code>-EFAULT</code>
| -14
| Bad address
| copy_to_user/copy_from_user failed
|-
| <code>-EINVAL</code>
| -22
| Invalid argument
| Invalid ioctl command, bad parameter
|-
| <code>-ENOMEM</code>
| -12
| Out of memory
| kmalloc() failed
|-
| <code>-ENOSPC</code>
| -28
| No space left
| Device buffer full
|-
| <code>-ENODEV</code>
| -19
| No such device
| Device not found/initialized
|-
| <code>-EBUSY</code>
| -16
| Device busy
| Resource in use
|-
| <code>-EIO</code>
| -5
| I/O error
| Hardware error
|}

'''How to use:'''

<syntaxhighlight lang="c">if (!buffer) {
return -ENOMEM; /* Allocation failed */
}

if (copy_from_user(buffer, user_ptr, len)) {
return -EFAULT; /* Bad pointer from userspace */
}

if (cmd != VALID_COMMAND) {
return -EINVAL; /* Invalid command */
}</syntaxhighlight>
Userspace sees these as errno values:

<syntaxhighlight lang="c">/* Userspace code */
if (write(fd, data, len) < 0) {
perror("write"); /* Prints "write: Bad address" for -EFAULT */
}</syntaxhighlight>

=== Synchronization: Protecting Shared Data ===


==== The Concurrency Problem ====

Your kernel module can be accessed by multiple processes simultaneously. Consider this scenario:

<pre>Time Process A Process B
---- --------------------- ---------------------
1 open("/dev/superpipe")
2 write("hello") open("/dev/superpipe")
3 [writing to buffer] write("world")
4 [writing to buffer] [writing to buffer] ← RACE!
5 [writing to buffer] ← DATA CORRUPTION!</pre>
Without synchronization, both processes could write to the buffer simultaneously, resulting in garbled data, corrupted state, or kernel crashes.

'''Types of concurrency:'''

# '''Multiple processes:''' Different processes calling your module
# '''Multiple threads:''' Threads in the same process
# '''Interrupts:''' Interrupt handlers can preempt your code
# '''Multiple CPUs:''' Code running simultaneously on different CPU cores

'''The shared state problem:'''

<syntaxhighlight lang="c">/* Global device state - shared by all processes */
static struct {
char buffer[4096];
size_t len;
} dev_state;

/* UNSAFE - race condition! */
static ssize_t unsafe_write(...) {
/* What if another process modifies dev_state.len right here? */
memcpy(&dev_state.buffer[dev_state.len], data, count);
dev_state.len += count; /* Race! Another write could have happened */
}</syntaxhighlight>

==== Mutexes in the Kernel ====

A '''mutex''' (mutual exclusion lock) ensures that only one thread can access a critical section at a time.

'''Declaring a mutex:'''

<syntaxhighlight lang="c">#include <linux/mutex.h>

static DEFINE_MUTEX(my_mutex); /* Declares and initializes */

/* Or for dynamic initialization: */
struct mutex my_mutex;
mutex_init(&my_mutex);</syntaxhighlight>
'''Using a mutex:'''

<syntaxhighlight lang="c">/* Acquire lock - will sleep if already held */
mutex_lock(&my_mutex);

/* Critical section - only one thread at a time */
/* Access shared data here */

/* Release lock */
mutex_unlock(&my_mutex);</syntaxhighlight>
'''Interruptible locking:'''

In syscall handlers (read, write, ioctl), use the interruptible version so users can interrupt with Ctrl+C:

<syntaxhighlight lang="c">/* Try to acquire lock, but allow signals to interrupt */
if (mutex_lock_interruptible(&my_mutex)) {
return -ERESTARTSYS; /* System call was interrupted */
}

/* Critical section */

mutex_unlock(&my_mutex);</syntaxhighlight>
'''Safe write example:'''

<syntaxhighlight lang="c">static DEFINE_MUTEX(device_mutex);

static ssize_t safe_write(struct file *file, const char __user *user_buffer,
size_t count, loff_t *offset)
{
/* Acquire lock */
if (mutex_lock_interruptible(&device_mutex))
return -ERESTARTSYS;

/* Critical section - safe from concurrent access */
if (dev_state.len + count > BUFFER_SIZE) {
mutex_unlock(&device_mutex);
return -ENOSPC;
}

if (copy_from_user(&dev_state.buffer[dev_state.len], user_buffer, count)) {
mutex_unlock(&device_mutex);
return -EFAULT;
}

dev_state.len += count;

/* Release lock */
mutex_unlock(&device_mutex);
return count;
}</syntaxhighlight>
'''Rules for mutex usage:'''

# '''Always release:''' Every lock must have a corresponding unlock (even on error paths)
# '''Short critical sections:''' Hold locks for the minimum time necessary
# '''No sleeping with spinlocks:''' Don't use mutexes in interrupt context (use spinlocks instead)
# '''Avoid deadlocks:''' Don't acquire multiple locks, or always acquire in the same order


=== The ioctl Interface: Device-Specific Commands ===


==== What is ioctl? ====

The standard file operations (<code>read</code>, <code>write</code>) are generic—they work the same way across all devices. But sometimes you need device-specific operations that don't fit the read/write model:

* Configure a serial port's baud rate
* Set video resolution on a graphics device
* Enable a network interface
* Set transformation mode on our superpipe device

This is what <code>ioctl()</code> (input/output control) is for: device-specific commands that go beyond simple data transfer.

'''Userspace signature:'''

<syntaxhighlight lang="c">#include <sys/ioctl.h>

int ioctl(int fd, unsigned long request, ...);</syntaxhighlight>
'''Parameters:'''

* <code>fd</code>: File descriptor
* <code>request</code>: Command code (defined by driver)
* <code>...</code>: Optional argument (pointer or value)

'''Example usage:'''

<syntaxhighlight lang="c">int fd = open("/dev/superpipe", O_RDWR);

/* Simple command with no data */
ioctl(fd, SUPERPIPE_IOC_RESET);

/* Command that passes a value */
int mode = TRANSFORM_UPPER;
ioctl(fd, SUPERPIPE_IOC_SET_MODE, mode);

/* Command that passes a structure */
struct superpipe_config cfg = { .mode = TRANSFORM_UPPER };
ioctl(fd, SUPERPIPE_IOC_SET_CONFIG, &cfg);</syntaxhighlight>

==== Defining ioctl Commands ====

ioctl commands are unsigned integers, but they're not arbitrary—they're constructed using macros that encode information about the command.

'''Command encoding:'''

<pre> Direction | Size of data | Magic | Sequence
____________|______________|_______|__________
| 2 bits | 14 bits | 8 bits | 8 bits |
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾</pre>
'''The macros:'''

<syntaxhighlight lang="c">#include <linux/ioctl.h>

_IO(magic, number) /* No data transfer */
_IOR(magic, number, datatype) /* Read from device (copy_to_user) */
_IOW(magic, number, datatype) /* Write to device (copy_from_user) */
_IOWR(magic, number, datatype) /* Both read and write */</syntaxhighlight>
'''Parameters:'''

* <code>magic</code>: 8-bit magic number (identifies your driver, typically a character)
* <code>number</code>: Command number (sequential numbering)
* <code>datatype</code>: Type of data being transferred (for size encoding)

'''Example:'''

<syntaxhighlight lang="c">#define SUPERPIPE_IOC_MAGIC 'k'

/* No data transfer */
#define SUPERPIPE_IOC_RESET _IO(SUPERPIPE_IOC_MAGIC, 0)

/* Write an integer to device */
#define SUPERPIPE_IOC_SET_MODE _IOW(SUPERPIPE_IOC_MAGIC, 1, int)

/* Read an integer from device */
#define SUPERPIPE_IOC_GET_MODE _IOR(SUPERPIPE_IOC_MAGIC, 2, int)

/* Read and write a structure */
#define SUPERPIPE_IOC_CONFIG _IOWR(SUPERPIPE_IOC_MAGIC, 3, struct superpipe_config)</syntaxhighlight>
'''Why use macros instead of simple numbers?'''

# '''Type safety:''' Encodes the size of the data being transferred
# '''Direction:''' Indicates whether data flows to/from device
# '''Collision avoidance:''' Magic number helps avoid conflicts with other drivers
# '''Self-documenting:''' The macro tells you what the command does


==== Passing Structures with ioctl ====

For complex configuration, passing structures is more flexible than passing simple values.

'''Define the structure (in UAPI header, shared between kernel and userspace):'''

<syntaxhighlight lang="c">/* superpipe_uapi.h */
struct superpipe_ioctl_config {
__u32 mode; /* Transformation mode */
__u32 flags; /* Additional flags (for future expansion) */
};</syntaxhighlight>
'''Note:''' Use <code>__u32</code>, <code>__u64</code>, etc. (double underscore types) in UAPI headers. These are guaranteed to have the same size in both 32-bit and 64-bit architectures.

'''Define the ioctl command:'''

<syntaxhighlight lang="c">#define SUPERPIPE_IOC_SET_CONFIG _IOW(SUPERPIPE_IOC_MAGIC, 1, struct superpipe_ioctl_config)
#define SUPERPIPE_IOC_GET_CONFIG _IOR(SUPERPIPE_IOC_MAGIC, 2, struct superpipe_ioctl_config)</syntaxhighlight>
'''Userspace usage:'''

<syntaxhighlight lang="c">#include "superpipe_uapi.h"

int fd = open("/dev/superpipe", O_RDWR);

struct superpipe_ioctl_config cfg = {
.mode = TRANSFORM_UPPER,
.flags = 0,
};

if (ioctl(fd, SUPERPIPE_IOC_SET_CONFIG, &cfg) < 0) {
perror("ioctl");
}</syntaxhighlight>
'''Kernel implementation:'''

<syntaxhighlight lang="c">static long superpipe_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
struct superpipe_ioctl_config cfg;

switch (cmd) {
case SUPERPIPE_IOC_SET_CONFIG:
/* Copy structure from userspace */
if (copy_from_user(&cfg, (void __user *)arg, sizeof(cfg)))
return -EFAULT;

/* Validate */
if (cfg.mode >= TRANSFORM_MAX)
return -EINVAL;

/* Apply configuration */
device_state.mode = cfg.mode;
return 0;

case SUPERPIPE_IOC_GET_CONFIG:
/* Prepare structure */
cfg.mode = device_state.mode;
cfg.flags = 0;

/* Copy to userspace */
if (copy_to_user((void __user *)arg, &cfg, sizeof(cfg)))
return -EFAULT;

return 0;

default:
return -EINVAL; /* Unknown command */
}
}</syntaxhighlight>
'''Key points:'''

# '''arg is a userspace pointer:''' Must use copy_from_user/copy_to_user
# '''Validate inputs:''' Check that values are in valid ranges
# '''Return 0 on success:''' Negative error code on failure
# '''Handle unknown commands:''' Return -EINVAL for commands you don't recognize


=== The UAPI Header: Sharing Definitions ===


==== What is UAPI? ====

UAPI stands for "User API"—definitions that are shared between kernel code and userspace code. In the Linux kernel source tree, these headers live in <code>include/uapi/linux/</code>.

'''Why separate UAPI headers?'''

# '''Single source of truth:''' Define ioctl commands, structures, constants once
# '''Consistency:''' Kernel and userspace always agree on command values and structure layouts
# '''Stability:''' UAPI is part of the kernel's stable ABI—once defined, it shouldn't change (backward compatibility)
# '''Clear boundary:''' Clearly separates internal kernel definitions from external interface

'''What goes in a UAPI header?'''

* ioctl command definitions
* Structure definitions for data passed between kernel and userspace
* Constant definitions (modes, flags, limits)
* Enum definitions used in the interface

'''What does NOT go in a UAPI header?'''

* Internal kernel structures
* Function declarations
* Kernel-only constants

'''Our UAPI header structure:'''

<syntaxhighlight lang="c">/* superpipe_uapi.h - Shared between kernel and userspace */
#ifndef _SUPERPIPE_UAPI_H
#define _SUPERPIPE_UAPI_H

#include <linux/ioctl.h>
#include <linux/types.h> /* For __u32, __u64, etc. */

/* Transform modes */
#define SUPERPIPE_MODE_NONE 0
#define SUPERPIPE_MODE_UPPER 1
#define SUPERPIPE_MODE_LOWER 2
#define SUPERPIPE_MODE_DROP_VOWELS 3
#define SUPERPIPE_MODE_DROP_SPACES 4

/* Configuration structure */
struct superpipe_ioctl_config {
__u32 mode; /* One of SUPERPIPE_MODE_* */
__u32 flags; /* Reserved for future use */
};

/* ioctl commands */
#define SUPERPIPE_IOC_MAGIC 'k'

#define SUPERPIPE_IOC_SET_CONFIG _IOW(SUPERPIPE_IOC_MAGIC, 1, struct superpipe_ioctl_config)
#define SUPERPIPE_IOC_GET_CONFIG _IOR(SUPERPIPE_IOC_MAGIC, 2, struct superpipe_ioctl_config)
#define SUPERPIPE_IOC_RESET _IO(SUPERPIPE_IOC_MAGIC, 3)

#endif /* _SUPERPIPE_UAPI_H */</syntaxhighlight>
'''Using in kernel code:'''

<syntaxhighlight lang="c">/* superpipe.c */
#include "superpipe_uapi.h"

static long superpipe_ioctl(...)
{
struct superpipe_ioctl_config cfg;

switch (cmd) {
case SUPERPIPE_IOC_SET_CONFIG:
/* Use the definitions from UAPI header */
if (copy_from_user(&cfg, ...))
return -EFAULT;

if (cfg.mode == SUPERPIPE_MODE_UPPER) {
/* ... */
}
break;
}
}</syntaxhighlight>
'''Using in userspace code:'''

<syntaxhighlight lang="c">/* test_superpipe.c */
#include "superpipe_uapi.h" /* Same header! */

int main()
{
struct superpipe_ioctl_config cfg = {
.mode = SUPERPIPE_MODE_UPPER,
.flags = 0,
};

ioctl(fd, SUPERPIPE_IOC_SET_CONFIG, &cfg);
}</syntaxhighlight>
'''Benefits:'''

* Change command codes in one place
* Add new modes without editing two files
* Compiler catches mismatches automatically
* Standard Linux kernel practice


== Design: The Superpipe Device ==


=== Device Behavior ===

The superpipe device implements a buffered pipe with configurable byte transformations. Here's the complete behavior specification:

'''Basic operations:'''

# '''Write:''' Userspace writes data → Kernel applies transformation → Stores in buffer
# '''Read:''' Kernel copies data from buffer → Returns to userspace → Removes from buffer (consuming read)
# '''ioctl:''' Userspace sends configuration → Kernel updates transformation mode

'''Buffer properties:'''

* '''Size:''' 4096 bytes (4KB)
* '''Type:''' Circular/linear buffer (your choice)
* '''Behavior when full:''' write() returns -ENOSPC
* '''Behavior when empty:''' read() returns 0 (EOF)

'''Transformation timing:'''

Data is transformed '''during write''', not during read.

'''Example flow:'''

<pre>Time Action Buffer State Mode
---- ------------------------------ ----------------- -----------
1 ioctl(SET_CONFIG, NONE) [] NONE
2 write("Hello") ["Hello"] NONE
3 read() → "Hello" [] NONE
4 ioctl(SET_CONFIG, UPPER) [] UPPER
5 write("world") ["WORLD"] UPPER
6 read() → "WORLD" [] UPPER
7 ioctl(SET_CONFIG, NONE) [] NONE
8 write("test") ["test"] NONE
9 ioctl(SET_CONFIG, UPPER) ["test"] UPPER (mode change doesn't affect existing data!)
10 write("NEW") ["testNEW"] UPPER
11 read() → "testNEW" [] UPPER</pre>
'''Key insight from example:'''

At time 9, we change mode to UPPER, but the existing data "test" stays lowercase. Only NEW data (written after the mode change) gets transformed. This is a consequence of transform-on-write: once data is in the buffer, its transformation is "baked in."

'''Implementation:'''

<syntaxhighlight lang="c">/* Pseudo-code for transform-on-write */
static ssize_t superpipe_write(...)
{
char *write_position;
size_t final_len;

/* Copy from userspace to buffer */
write_position = buffer + buffer_len;
copy_from_user(write_position, user_data, count);

/* Transform in-place immediately */
final_len = count; /* Start with bytes copied */
switch (mode) {
case TRANSFORM_UPPER:
transform_upper(write_position, count);
/* final_len stays count - no compaction */
break;
case TRANSFORM_DROP_VOWELS:
final_len = transform_drop_vowels(write_position, count);
/* final_len may be less than count - data compacted */
break;
}

/* Update buffer length by actual stored bytes */
buffer_len += final_len;

/* Return bytes consumed from user, not bytes stored */
return count; /* Standard UNIX semantics */
}</syntaxhighlight>
'''Note for filtering transforms:''' When dropping characters (vowels, spaces), the amount of data stored may be less than the amount written. The write() call returns the actual number of bytes stored after filtering.


=== Device State Structure ===

All device state is stored in a single global structure:

<syntaxhighlight lang="c">/* Transform modes - internal to kernel */
enum transform_mode {
TRANSFORM_NONE = 0,
TRANSFORM_UPPER,
TRANSFORM_LOWER,
TRANSFORM_DROP_VOWELS,
TRANSFORM_DROP_SPACES,
TRANSFORM_MAX /* Sentinel for validation */
};

/* Device state */
struct superpipe_device {
char *buffer; /* Kernel buffer (allocated with kmalloc) */
size_t buffer_len; /* Current amount of data in buffer */
struct mutex lock; /* Protects buffer and mode from concurrent access */
enum transform_mode mode; /* Current transformation mode */
};

static struct superpipe_device dev_state;</syntaxhighlight>
'''Design notes:'''

'''Global state:''' We use a single global structure because we have exactly one device instance (<code>/dev/superpipe</code>). All opens share the same buffer and transformation mode.

'''Alternative designs:'''

* '''Per-file state:''' Each open() could have independent buffer and mode (use file->private_data)
* '''Embedded miscdevice:''' Embed miscdevice in device structure, use container_of() to access

For this lab, global state is simpler and clearer for learning.

'''Initialization:'''

<syntaxhighlight lang="c">static int __init superpipe_init(void)
{
/* Allocate buffer */
dev_state.buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);
if (!dev_state.buffer)
return -ENOMEM;

/* Initialize state */
dev_state.buffer_len = 0;
dev_state.mode = TRANSFORM_NONE;
mutex_init(&dev_state.lock);

/* Register device */
return misc_register(&superpipe_miscdev);
}</syntaxhighlight>
'''Cleanup:'''

<syntaxhighlight lang="c">static void __exit superpipe_exit(void)
{
misc_deregister(&superpipe_miscdev);
kfree(dev_state.buffer);
}</syntaxhighlight>

== Reference Implementation: Superpipe with Uppercase Transform ==

In this section, we present a complete, working kernel module that implements the superpipe device with support for two transformation modes: NONE (pass-through) and UPPER (convert to uppercase). This reference implementation demonstrates all the concepts covered in the theoretical background.

Study this code carefully. The exercise at the end asks you to extend it to support additional transformations.


=== UAPI Header: superpipe_uapi.h ===

This header is shared between kernel code and userspace programs.

<syntaxhighlight lang="c">/* superpipe_uapi.h - User API definitions for superpipe device */
#ifndef _SUPERPIPE_UAPI_H
#define _SUPERPIPE_UAPI_H

#include <linux/ioctl.h>
#include <linux/types.h>

/*
* Transform modes
* These constants identify which transformation to apply
*/
#define SUPERPIPE_MODE_NONE 0 /* Pass through unchanged */
#define SUPERPIPE_MODE_UPPER 1 /* Convert to uppercase */

/*
* Configuration structure
* Passed between userspace and kernel via ioctl
*/
struct superpipe_ioctl_config {
__u32 mode; /* One of SUPERPIPE_MODE_* constants */
__u32 flags; /* Reserved for future use (set to 0) */
};

/*
* ioctl commands
* Magic number 'k' chosen arbitrarily (could be any character)
*/
#define SUPERPIPE_IOC_MAGIC 'k'

/* Set transformation configuration (write config to device) */
#define SUPERPIPE_IOC_SET_CONFIG _IOW(SUPERPIPE_IOC_MAGIC, 1, struct superpipe_ioctl_config)

/* Get current configuration (read config from device) */
#define SUPERPIPE_IOC_GET_CONFIG _IOR(SUPERPIPE_IOC_MAGIC, 2, struct superpipe_ioctl_config)

/* Reset device (clear buffer) */
#define SUPERPIPE_IOC_RESET _IO(SUPERPIPE_IOC_MAGIC, 3)

#endif /* _SUPERPIPE_UAPI_H */</syntaxhighlight>

=== Kernel Module: superpipe_ref.c ===

This is the complete kernel module implementation.

<syntaxhighlight lang="c">/* superpipe_ref.c - Reference implementation of superpipe device */

#include <linux/module.h> /* Core module functionality */
#include <linux/kernel.h> /* Kernel types and macros */
#include <linux/init.h> /* module_init, module_exit */
#include <linux/miscdevice.h> /* Miscdevice framework */
#include <linux/fs.h> /* File operations structure */
#include <linux/uaccess.h> /* copy_to_user, copy_from_user */
#include <linux/mutex.h> /* Mutex synchronization */
#include <linux/slab.h> /* kmalloc, kfree */
#include <linux/ctype.h> /* toupper, tolower */

#include "superpipe_uapi.h" /* Shared UAPI definitions */

#define DEVICE_NAME "superpipe"
#define BUFFER_SIZE 4096

/*
* Internal transform modes
* Maps to UAPI constants but kept internal to module
*/
enum transform_mode {
TRANSFORM_NONE = SUPERPIPE_MODE_NONE,
TRANSFORM_UPPER = SUPERPIPE_MODE_UPPER,
TRANSFORM_MAX /* Sentinel for validation */
};

/*
* Device state structure
* All state is stored here (single global instance)
*/
struct superpipe_device {
char *buffer; /* Dynamically allocated kernel buffer */
size_t buffer_len; /* Current amount of data in buffer */
struct mutex lock; /* Protects all fields from concurrent access */
enum transform_mode mode; /* Current transformation mode */
};

/* Global device state (single instance for one device) */
static struct superpipe_device dev_state;

/*
* transform_upper - Apply uppercase transformation in-place
* @data: Pointer to data to transform
* @len: Length of data in bytes
*
* Converts all ASCII lowercase letters (a-z) to uppercase (A-Z).
* Other characters pass through unchanged.
*/
static void transform_upper(char *data, size_t len)
{
size_t i;

for (i = 0; i < len; i++) {
if (islower(data[i])) {
data[i] = toupper(data[i]);
}
}
}

/*
* superpipe_open - Handle device open
* @inode: Inode representing the device file
* @file: File structure for this open
*
* Called when userspace opens /dev/superpipe.
* We don't need to do anything special, just log the event.
*
* Return: 0 on success
*/
static int superpipe_open(struct inode *inode, struct file *file)
{
printk(KERN_INFO "superpipe: Device opened by process %d (%s)\n",
current->pid, current->comm);
return 0;
}

/*
* superpipe_release - Handle device close
* @inode: Inode representing the device file
* @file: File structure being closed
*
* Called when userspace closes /dev/superpipe.
* Cleanup would go here if we allocated per-file resources.
*
* Return: 0 on success
*/
static int superpipe_release(struct inode *inode, struct file *file)
{
printk(KERN_INFO "superpipe: Device closed by process %d (%s)\n",
current->pid, current->comm);
return 0;
}

/*
* superpipe_read - Handle read operation
* @file: File structure
* @user_buffer: Userspace buffer to copy data into
* @count: Number of bytes requested
* @offset: File offset (unused for character devices)
*
* Copies data from kernel buffer to userspace.
* Data is removed from buffer after reading (consuming read).
* With transform-on-write, data is already transformed, so we just copy.
*
* Return: Number of bytes read, 0 for EOF, negative error code on failure
*/
static ssize_t superpipe_read(struct file *file, char __user *user_buffer,
size_t count, loff_t *offset)
{
size_t to_copy;

/* Acquire lock - interruptible so Ctrl+C works */
if (mutex_lock_interruptible(&dev_state.lock))
return -ERESTARTSYS; /* Interrupted by signal */

/* Check if there's data available */
if (dev_state.buffer_len == 0) {
mutex_unlock(&dev_state.lock);
return 0; /* EOF - no data available */
}

/* Determine how much to copy: minimum of requested and available */
to_copy = (count < dev_state.buffer_len) ? count : dev_state.buffer_len;

/* Copy data to userspace - data is already transformed */
if (copy_to_user(user_buffer, dev_state.buffer, to_copy)) {
mutex_unlock(&dev_state.lock);
return -EFAULT; /* Bad userspace address */
}

/*
* Remove copied data from buffer by shifting remaining data forward
* There are more efficient ways to do this (eg. ring buffers)
*/
dev_state.buffer_len -= to_copy;
if (dev_state.buffer_len > 0) {
memmove(dev_state.buffer, dev_state.buffer + to_copy,
dev_state.buffer_len);
}

mutex_unlock(&dev_state.lock);

printk(KERN_INFO "superpipe: Read %zu bytes\n", to_copy);
return to_copy;
}

/*
* superpipe_write - Handle write operation
* @file: File structure
* @user_buffer: Userspace buffer containing data to write
* @count: Number of bytes to write
* @offset: File offset (unused for character devices)
*
* Copies data from userspace to kernel buffer, applying transformation.
* This is where transform-on-write happens: data is transformed as it
* enters the buffer, not when it's read out.
*
* Return: Number of bytes written, negative error code on failure
*/
static ssize_t superpipe_write(struct file *file,
const char __user *user_buffer,
size_t count, loff_t *offset)
{
size_t space_available;
size_t to_write;
char *write_position;

/* Acquire lock */
if (mutex_lock_interruptible(&dev_state.lock))
return -ERESTARTSYS;

/* Check available space in buffer */
space_available = BUFFER_SIZE - dev_state.buffer_len;
if (space_available == 0) {
mutex_unlock(&dev_state.lock);
return -ENOSPC; /* Buffer full - no space left */
}

/* Determine how much we can actually write */
to_write = (count < space_available) ? count : space_available;

/* Calculate where to write in buffer */
write_position = dev_state.buffer + dev_state.buffer_len;

/* Copy from userspace to kernel buffer */
if (copy_from_user(write_position, user_buffer, to_write)) {
mutex_unlock(&dev_state.lock);
return -EFAULT; /* Bad userspace address */
}

/*
* TRANSFORM ON WRITE
* Apply transformation to the newly written data in-place
* Data in buffer is always in its final transformed state
*/
switch (dev_state.mode) {
case TRANSFORM_UPPER:
transform_upper(write_position, to_write);
break;
case TRANSFORM_NONE:
/* No transformation - data already copied as-is */
break;
default:
/* Should never happen if validation is correct */
printk(KERN_WARNING "superpipe: Invalid mode %d\n", dev_state.mode);
break;
}

/* Update buffer length - for this reference, same as to_write */
dev_state.buffer_len += to_write;

mutex_unlock(&dev_state.lock);

printk(KERN_INFO "superpipe: Wrote %zu bytes (mode=%d)\n",
to_write, dev_state.mode);

/* Return bytes consumed from user buffer */
return to_write;
}

/*
* superpipe_ioctl - Handle ioctl commands
* @file: File structure
* @cmd: ioctl command code
* @arg: ioctl argument (pointer or value, depends on command)
*
* Handles device-specific configuration commands.
* Commands are defined in superpipe_uapi.h
*
* Return: 0 on success, negative error code on failure
*/
static long superpipe_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
struct superpipe_ioctl_config cfg;
int ret = 0;

/* Acquire lock */
if (mutex_lock_interruptible(&dev_state.lock))
return -ERESTARTSYS;

switch (cmd) {
case SUPERPIPE_IOC_SET_CONFIG:
/* Copy configuration structure from userspace */
if (copy_from_user(&cfg, (void __user *)arg, sizeof(cfg))) {
ret = -EFAULT;
break;
}

/* Validate mode */
if (cfg.mode >= TRANSFORM_MAX) {
printk(KERN_WARNING "superpipe: Invalid mode %u\n", cfg.mode);
ret = -EINVAL;
break;
}

/* Apply configuration */
dev_state.mode = cfg.mode;
printk(KERN_INFO "superpipe: Mode set to %u\n", cfg.mode);
break;

case SUPERPIPE_IOC_GET_CONFIG:
/* Prepare configuration structure */
cfg.mode = dev_state.mode;
cfg.flags = 0;

/* Copy to userspace */
if (copy_to_user((void __user *)arg, &cfg, sizeof(cfg))) {
ret = -EFAULT;
break;
}

printk(KERN_INFO "superpipe: Returned config (mode=%u)\n", cfg.mode);
break;

case SUPERPIPE_IOC_RESET:
/* Clear buffer */
dev_state.buffer_len = 0;
printk(KERN_INFO "superpipe: Buffer reset\n");
break;

default:
/* Unknown command */
printk(KERN_WARNING "superpipe: Unknown ioctl command: 0x%x\n", cmd);
ret = -EINVAL;
break;
}

mutex_unlock(&dev_state.lock);
return ret;
}

/*
* File operations structure
* Maps system calls to our handler functions
*/
static const struct file_operations superpipe_fops = {
.owner = THIS_MODULE,
.open = superpipe_open,
.release = superpipe_release,
.read = superpipe_read,
.write = superpipe_write,
.unlocked_ioctl = superpipe_ioctl,
};

/*
* Miscdevice structure
* Defines our character device
*/
static struct miscdevice superpipe_miscdev = {
.minor = MISC_DYNAMIC_MINOR, /* Kernel assigns minor number automatically */
.name = DEVICE_NAME, /* Creates /dev/superpipe */
.fops = &superpipe_fops, /* Our file operations */
.mode = 0666, /* Device permissions (rw-rw-rw-) */
};

/*
* superpipe_init - Module initialization
*
* Called when module is loaded with insmod.
* Allocates resources and registers the device.
*
* Return: 0 on success, negative error code on failure
*/
static int __init superpipe_init(void)
{
int ret;

/* Allocate kernel buffer (4KB) */
dev_state.buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);
if (!dev_state.buffer) {
printk(KERN_ERR "superpipe: Failed to allocate buffer\n");
return -ENOMEM;
}

/* Initialize device state */
dev_state.buffer_len = 0;
dev_state.mode = TRANSFORM_NONE; /* Start in pass-through mode */
mutex_init(&dev_state.lock);

/* Register miscdevice - creates /dev/superpipe */
ret = misc_register(&superpipe_miscdev);
if (ret) {
printk(KERN_ERR "superpipe: Failed to register device (error %d)\n", ret);
kfree(dev_state.buffer);
return ret;
}

printk(KERN_INFO "superpipe: Module loaded successfully\n");
printk(KERN_INFO "superpipe: Device created at /dev/%s\n", DEVICE_NAME);
printk(KERN_INFO "superpipe: Buffer size: %d bytes\n", BUFFER_SIZE);
return 0;
}

/*
* superpipe_exit - Module cleanup
*
* Called when module is unloaded with rmmod.
* Unregisters device and frees resources.
*/
static void __exit superpipe_exit(void)
{
/* Unregister device - removes /dev/superpipe */
misc_deregister(&superpipe_miscdev);

/* Free buffer */
kfree(dev_state.buffer);

printk(KERN_INFO "superpipe: Module unloaded\n");
}

/* Register initialization and cleanup functions */
module_init(superpipe_init);
module_exit(superpipe_exit);

/* Module metadata */
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name <your.email@example.com>");
MODULE_DESCRIPTION("Superpipe character device with configurable transformations");
MODULE_VERSION("1.0");</syntaxhighlight>

=== Understanding the Reference Implementation ===

Let's walk through the key components of this implementation.


==== Module Initialization ====

<syntaxhighlight lang="c">static int __init superpipe_init(void)
{
/* 1. Allocate buffer */
dev_state.buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);

/* 2. Initialize state */
dev_state.buffer_len = 0;
dev_state.mode = TRANSFORM_NONE;
mutex_init(&dev_state.lock);

/* 3. Register device */
ret = misc_register(&superpipe_miscdev);
}</syntaxhighlight>
'''Step-by-step:'''

# '''Allocate buffer:''' <code>kmalloc()</code> is the kernel equivalent of <code>malloc()</code>. <code>GFP_KERNEL</code> means "can sleep, normal priority allocation."
# '''Initialize state:''' Set buffer empty, mode to pass-through, initialize mutex
# '''Register device:''' This creates <code>/dev/superpipe</code> and makes it available

'''If anything fails:''' Clean up already-allocated resources before returning error code.


==== The Open Handler ====

<syntaxhighlight lang="c">static int superpipe_open(struct inode *inode, struct file *file)
{
printk(KERN_INFO "superpipe: Device opened by process %d (%s)\n",
current->pid, current->comm);
return 0;
}</syntaxhighlight>
'''What happens here:'''

* <code>current</code> is a kernel global pointing to the current process's task_struct
* <code>current->pid</code> is the process ID
* <code>current->comm</code> is the process name (from argv[0])
* We don't need to allocate per-file resources, so just log and return success


==== The Write Handler: Transform-on-Write ====

<syntaxhighlight lang="c">static ssize_t superpipe_write(...)
{
/* 1. Acquire lock */
mutex_lock_interruptible(&dev_state.lock);

/* 2. Check space */
if (space_available == 0)
return -ENOSPC;

/* 3. Copy from user */
write_position = dev_state.buffer + dev_state.buffer_len;
copy_from_user(write_position, user_buffer, to_write);

/* 4. TRANSFORM IN-PLACE */
switch (dev_state.mode) {
case TRANSFORM_UPPER:
transform_upper(write_position, to_write);
break;
}

/* 5. Update length */
dev_state.buffer_len += to_write;

/* 6. Release lock */
mutex_unlock(&dev_state.lock);

return to_write;
}</syntaxhighlight>
'''Key points:'''

* Data is transformed immediately after being copied from userspace
* The transformation happens on <code>write_position</code> (the buffer location), not a temporary copy
* Once stored, data is in its final transformed state


==== The Read Handler: Simple Copy ====

<syntaxhighlight lang="c">static ssize_t superpipe_read(...)
{
/* 1. Check for data */
if (dev_state.buffer_len == 0)
return 0; /* EOF */

/* 2. Copy to user - data already transformed */
copy_to_user(user_buffer, dev_state.buffer, to_copy);

/* 3. Remove consumed data */
dev_state.buffer_len -= to_copy;
memmove(dev_state.buffer, dev_state.buffer + to_copy,
dev_state.buffer_len);

return to_copy;
}</syntaxhighlight>
'''Why it's simple:'''

* No transformation needed—data is already in final form
* Just copy to userspace and remove from buffer
* <code>memmove()</code> shifts remaining data to the beginning


==== The ioctl Handler: Configuration with Structs ====

<syntaxhighlight lang="c">static long superpipe_ioctl(...)
{
struct superpipe_ioctl_config cfg;

switch (cmd) {
case SUPERPIPE_IOC_SET_CONFIG:
/* 1. Copy struct from userspace */
if (copy_from_user(&cfg, (void __user *)arg, sizeof(cfg)))
return -EFAULT;

/* 2. Validate */
if (cfg.mode >= TRANSFORM_MAX)
return -EINVAL;

/* 3. Apply */
dev_state.mode = cfg.mode;
break;

case SUPERPIPE_IOC_GET_CONFIG:
/* 1. Prepare struct */
cfg.mode = dev_state.mode;
cfg.flags = 0;

/* 2. Copy to userspace */
if (copy_to_user((void __user *)arg, &cfg, sizeof(cfg)))
return -EFAULT;
break;
}

return 0;
}</syntaxhighlight>
'''Pattern for struct-based ioctl:'''

# For SET (write to device): <code>copy_from_user</code> → validate → apply
# For GET (read from device): prepare → <code>copy_to_user</code>
# Always validate inputs before applying


==== Module Cleanup ====

<syntaxhighlight lang="c">static void __exit superpipe_exit(void)
{
misc_deregister(&superpipe_miscdev); /* Remove device */
kfree(dev_state.buffer); /* Free buffer */
}</syntaxhighlight>
'''Cleanup must:'''

* Undo everything done in init
* Be safe to call even if init partially failed (though our init handles that)
* Not leak resources


== Compiling and Testing the Reference Implementation ==


=== Step 1: Compile the Module ===

Create a <code>Makefile</code>:

<syntaxhighlight lang="makefile">obj-m += superpipe_ref.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

all:
$(MAKE) -C $(KDIR) M=$(PWD) modules

clean:
$(MAKE) -C $(KDIR) M=$(PWD) clean</syntaxhighlight>
'''Compile:'''

<syntaxhighlight lang="bash">make</syntaxhighlight>
'''Expected output:'''

<pre>make -C /lib/modules/6.5.0-generic/build M=/home/user/lab11 modules
make[1]: Entering directory '/usr/src/linux-headers-6.5.0-generic'
CC [M] /home/user/lab11/superpipe_ref.o
MODPOST /home/user/lab11/Module.symvers
CC [M] /home/user/lab11/superpipe_ref.mod.o
LD [M] /home/user/lab11/superpipe_ref.ko
make[1]: Leaving directory '/usr/src/linux-headers-6.5.0-generic'</pre>
You now have <code>superpipe_ref.ko</code> (kernel object file).


=== Step 2: Load the Module ===

'''Load the module:'''

<syntaxhighlight lang="bash">sudo insmod superpipe_ref.ko</syntaxhighlight>
'''Verify it loaded:'''

<syntaxhighlight lang="bash">lsmod | grep superpipe</syntaxhighlight>
'''Expected output:'''

<pre>superpipe_ref 16384 0</pre>
The "0" means no one is currently using it.

'''Check kernel messages:'''

<syntaxhighlight lang="bash">sudo dmesg | tail -5</syntaxhighlight>
'''Expected output:'''

<pre>[12345.678] superpipe: Module loaded successfully
[12345.678] superpipe: Device created at /dev/superpipe
[12345.678] superpipe: Buffer size: 4096 bytes</pre>
'''Verify device file:'''

<syntaxhighlight lang="bash">ls -l /dev/superpipe</syntaxhighlight>
'''Expected output:'''

<pre>crw-rw-rw- 1 root root 10, 58 Dec 19 12:00 /dev/superpipe</pre>
The device is ready to use!


=== Step 3: Build the Test Program ===

Create <code>test_superpipe.c</code>:

<syntaxhighlight lang="c">/* test_superpipe.c - Userspace test program for superpipe */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <errno.h>

#include "superpipe_uapi.h"

void usage(const char *progname)
{
fprintf(stderr, "Usage: %s <command> [args]\n", progname);
fprintf(stderr, "Commands:\n");
fprintf(stderr, " set_mode <none|upper> - Set transformation mode\n");
fprintf(stderr, " get_mode - Get current mode\n");
fprintf(stderr, " write <text> - Write text to device\n");
fprintf(stderr, " read - Read from device\n");
fprintf(stderr, " reset - Reset device (clear buffer)\n");
exit(1);
}

int main(int argc, char *argv[])
{
int fd;
struct superpipe_ioctl_config cfg;
char buffer[256];
ssize_t n;

if (argc < 2) {
usage(argv[0]);
}

/* Open device */
fd = open("/dev/superpipe", O_RDWR);
if (fd < 0) {
perror("Failed to open /dev/superpipe");
fprintf(stderr, "Make sure the module is loaded\n");
return 1;
}

/* Process command */
if (strcmp(argv[1], "set_mode") == 0) {
if (argc < 3) {
fprintf(stderr, "Error: set_mode requires mode argument\n");
close(fd);
return 1;
}

if (strcmp(argv[2], "none") == 0) {
cfg.mode = SUPERPIPE_MODE_NONE;
} else if (strcmp(argv[2], "upper") == 0) {
cfg.mode = SUPERPIPE_MODE_UPPER;
} else {
fprintf(stderr, "Error: Unknown mode '%s'\n", argv[2]);
close(fd);
return 1;
}

cfg.flags = 0;

if (ioctl(fd, SUPERPIPE_IOC_SET_CONFIG, &cfg) < 0) {
perror("ioctl SET_CONFIG");
close(fd);
return 1;
}

printf("✓ Mode set to %s\n", argv[2]);

} else if (strcmp(argv[1], "get_mode") == 0) {
if (ioctl(fd, SUPERPIPE_IOC_GET_CONFIG, &cfg) < 0) {
perror("ioctl GET_CONFIG");
close(fd);
return 1;
}

printf("Current mode: ");
switch (cfg.mode) {
case SUPERPIPE_MODE_NONE:
printf("NONE\n");
break;
case SUPERPIPE_MODE_UPPER:
printf("UPPER\n");
break;
default:
printf("UNKNOWN (%u)\n", cfg.mode);
break;
}

} else if (strcmp(argv[1], "write") == 0) {
if (argc < 3) {
fprintf(stderr, "Error: write requires text argument\n");
close(fd);
return 1;
}

n = write(fd, argv[2], strlen(argv[2]));
if (n < 0) {
perror("write");
close(fd);
return 1;
}

printf("✓ Wrote %zd bytes\n", n);

} else if (strcmp(argv[1], "read") == 0) {
n = read(fd, buffer, sizeof(buffer) - 1);
if (n < 0) {
perror("read");
close(fd);
return 1;
}

if (n == 0) {
printf("(no data available)\n");
} else {
buffer[n] = '\0';
printf("%s\n", buffer);
}

} else if (strcmp(argv[1], "reset") == 0) {
if (ioctl(fd, SUPERPIPE_IOC_RESET) < 0) {
perror("ioctl RESET");
close(fd);
return 1;
}

printf("✓ Device reset\n");

} else {
fprintf(stderr, "Error: Unknown command '%s'\n", argv[1]);
close(fd);
usage(argv[0]);
}

close(fd);
return 0;
}</syntaxhighlight>
'''Compile:'''

<syntaxhighlight lang="bash">gcc -o test_superpipe test_superpipe.c</syntaxhighlight>

=== Step 4: Test Basic Write and Read ===

'''Test pass-through mode:'''

<syntaxhighlight lang="bash">./test_superpipe set_mode none
./test_superpipe write "Hello World 123"
./test_superpipe read</syntaxhighlight>
'''Expected output:'''

<pre>✓ Mode set to none
✓ Wrote 15 bytes
Hello World 123</pre>
The data passes through unchanged.


=== Step 5: Test Uppercase Transformation ===

'''Enable uppercase mode and test:'''

<syntaxhighlight lang="bash">./test_superpipe set_mode upper
./test_superpipe write "hello world 123"
./test_superpipe read</syntaxhighlight>
'''Expected output:'''

<pre>✓ Mode set to upper
✓ Wrote 15 bytes
HELLO WORLD 123</pre>
The data was transformed to uppercase during the write!


=== Step 6: Test Mixed Mode Writes ===

'''Test that mode changes only affect new writes:'''

<syntaxhighlight lang="bash">./test_superpipe set_mode none
./test_superpipe write "plain "
./test_superpipe set_mode upper
./test_superpipe write "caps "
./test_superpipe set_mode none
./test_superpipe write "normal"
./test_superpipe read</syntaxhighlight>
'''Expected output:'''

<pre>✓ Mode set to none
✓ Wrote 6 bytes
✓ Mode set to upper
✓ Wrote 5 bytes
✓ Mode set to none
✓ Wrote 6 bytes
plain CAPS normal</pre>
Each write was transformed according to the mode at the time of writing!


=== Step 7: View Kernel Messages ===

'''Check what the kernel logged:'''

<syntaxhighlight lang="bash">sudo dmesg | tail -20</syntaxhighlight>
'''Expected output:'''

<pre>[12345.678] superpipe: Module loaded successfully
[12345.678] superpipe: Device created at /dev/superpipe
[12346.123] superpipe: Device opened by process 1234 (test_superpipe)
[12346.124] superpipe: Mode set to 0
[12346.125] superpipe: Device closed by process 1234 (test_superpipe)
[12346.200] superpipe: Device opened by process 1235 (test_superpipe)
[12346.201] superpipe: Wrote 15 bytes (mode=0)
[12346.202] superpipe: Device closed by process 1235 (test_superpipe)
[12346.300] superpipe: Device opened by process 1236 (test_superpipe)
[12346.301] superpipe: Read 15 bytes
[12346.302] superpipe: Device closed by process 1236 (test_superpipe)
...</pre>
You can see every open, close, read, write, and ioctl operation logged.


=== Step 8: Unload the Module ===

'''Unload:'''

<syntaxhighlight lang="bash">sudo rmmod superpipe_ref</syntaxhighlight>
'''Verify device is gone:'''

<syntaxhighlight lang="bash">ls -l /dev/superpipe</syntaxhighlight>
'''Expected:'''

<pre>ls: cannot access '/dev/superpipe': No such file or directory</pre>
'''Check kernel log:'''

<syntaxhighlight lang="bash">sudo dmesg | tail -1</syntaxhighlight>
'''Expected:'''

<pre>[12350.456] superpipe: Module unloaded</pre>

== Exercise: Full Superpipe Implementation ==


=== Objective ===

Extend the reference implementation to support five transformation modes:

# '''NONE''' - Pass through unchanged (already implemented)
# '''UPPER''' - Convert to uppercase (already implemented)
# '''LOWER''' - Convert to lowercase (NEW)
# '''DROP_VOWELS''' - Remove vowels (a, e, i, o, u, A, E, I, O, U) (NEW)
# '''DROP_SPACES''' - Remove space characters (0x20) (NEW)


=== Requirements ===

'''1. Update the UAPI Header'''

Add new mode constants to <code>superpipe_uapi.h</code>:

<syntaxhighlight lang="c">#define SUPERPIPE_MODE_NONE 0
#define SUPERPIPE_MODE_UPPER 1
#define SUPERPIPE_MODE_LOWER 2 /* NEW */
#define SUPERPIPE_MODE_DROP_VOWELS 3 /* NEW */
#define SUPERPIPE_MODE_DROP_SPACES 4 /* NEW */</syntaxhighlight>
'''2. Implement Transformation Functions'''

Add three new transformation functions to your kernel module:

<syntaxhighlight lang="c">/* Convert to lowercase */
static void transform_lower(char *data, size_t len);

/* Remove vowels (returns new length after filtering) */
static size_t transform_drop_vowels(char *data, size_t len);

/* Remove spaces (returns new length after filtering) */
static size_t transform_drop_spaces(char *data, size_t len);</syntaxhighlight>
'''3. Update the Write Handler'''

Modify <code>superpipe_write()</code> to handle all transformation modes:

<syntaxhighlight lang="c">/* Apply transformation - filtering may reduce length */
size_t final_len = to_write;

switch (dev_state.mode) {
case TRANSFORM_NONE:
/* No transformation */
break;
case TRANSFORM_UPPER:
transform_upper(write_position, to_write);
break;
case TRANSFORM_LOWER:
transform_lower(write_position, to_write);
break;
case TRANSFORM_DROP_VOWELS:
final_len = transform_drop_vowels(write_position, to_write);
break;
case TRANSFORM_DROP_SPACES:
final_len = transform_drop_spaces(write_position, to_write);
break;
}

/* Update buffer length by actual stored data */
dev_state.buffer_len += final_len;

return final_len; /* Return bytes actually stored */</syntaxhighlight>
'''4. Update the Test Program'''

Add support for new modes in <code>test_superpipe.c</code>:

<syntaxhighlight lang="c">} else if (strcmp(argv[2], "lower") == 0) {
cfg.mode = SUPERPIPE_MODE_LOWER;
} else if (strcmp(argv[2], "drop_vowels") == 0) {
cfg.mode = SUPERPIPE_MODE_DROP_VOWELS;
} else if (strcmp(argv[2], "drop_spaces") == 0) {
cfg.mode = SUPERPIPE_MODE_DROP_SPACES;</syntaxhighlight>

=== Transformation Specifications ===

'''TRANSFORM_LOWER:'''

Convert all ASCII uppercase letters (A-Z) to lowercase (a-z). Other characters unchanged.

<pre>Input: "Hello WORLD 123"
Output: "hello world 123"</pre>
'''TRANSFORM_DROP_VOWELS:'''

Remove all vowels (both upper and lowercase): a, e, i, o, u, A, E, I, O, U

<pre>Input: "beautiful day"
Output: "btfl dy"

Input: "AEIOU"
Output: "" (empty)</pre>
'''TRANSFORM_DROP_SPACES:'''

Remove all space characters (ASCII 0x20)

<pre>Input: "hello world test"
Output: "helloworldtest"

Input: " spaces "
Output: "spaces"</pre>
'''Important for filtering transforms:'''

When characters are removed, the data must be compacted in the buffer. However, the write() system call still returns the number of bytes consumed from the user's buffer (standard UNIX behavior).

'''Example:'''

<syntaxhighlight lang="bash">./test_superpipe set_mode drop_vowels
./test_superpipe write "hello" # Writes 5 bytes
# Output: ✓ Wrote 5 bytes # Returns 5 (consumed all user data)
./test_superpipe read
# Output: hll # But only 3 bytes stored in buffer</syntaxhighlight>

=== Implementation Guidance ===

'''Helper function for vowel detection:'''

<syntaxhighlight lang="c">static inline bool is_vowel(char c)
{
return (c == 'a' || c == 'e' || c == 'i' || c == 'o' || c == 'u' ||
c == 'A' || c == 'E' || c == 'I' || c == 'O' || c == 'U');
}</syntaxhighlight>
'''Pattern for filtering (compacting) transformations:'''

<syntaxhighlight lang="c">static size_t transform_drop_vowels(char *data, size_t len)
{
size_t i, j = 0;

/* Iterate through input, copy only non-vowels */
for (i = 0; i < len; i++) {
if (!is_vowel(data[i])) {
data[j++] = data[i]; /* Keep this character */
}
/* Vowels are skipped - not copied to output position */
}

/* j now contains the number of characters kept */
return j;
}</syntaxhighlight>
'''Why this works:'''

* We iterate with <code>i</code> through all input characters
* We write kept characters to position <code>j</code>
* <code>j</code> only advances when we keep a character
* At the end, <code>j</code> is the new length

'''Pattern for case conversion:'''

<syntaxhighlight lang="c">static void transform_lower(char *data, size_t len)
{
size_t i;

for (i = 0; i < len; i++) {
if (isupper(data[i])) {
data[i] = tolower(data[i]);
}
}
}</syntaxhighlight>

=== Testing Requirements ===

Create a comprehensive test script <code>test.sh</code> that demonstrates:

'''Test 1: NONE mode'''

<syntaxhighlight lang="bash">./test_superpipe set_mode none
./test_superpipe write "Hello World 123"
./test_superpipe read
# Expected: Hello World 123</syntaxhighlight>
'''Test 2: UPPER mode'''

<syntaxhighlight lang="bash">./test_superpipe set_mode upper
./test_superpipe write "hello world 123"
./test_superpipe read
# Expected: HELLO WORLD 123</syntaxhighlight>
'''Test 3: LOWER mode'''

<syntaxhighlight lang="bash">./test_superpipe set_mode lower
./test_superpipe write "HELLO WORLD 123"
./test_superpipe read
# Expected: hello world 123</syntaxhighlight>
'''Test 4: DROP_VOWELS mode'''

<syntaxhighlight lang="bash">./test_superpipe set_mode drop_vowels
./test_superpipe write "beautiful"
./test_superpipe read
# Expected: btfl</syntaxhighlight>
'''Test 5: DROP_SPACES mode'''

<syntaxhighlight lang="bash">./test_superpipe set_mode drop_spaces
./test_superpipe write "hello world test"
./test_superpipe read
# Expected: helloworldtest</syntaxhighlight>
'''Test 6: Mixed modes (different modes for different writes)'''

<syntaxhighlight lang="bash">./test_superpipe set_mode none
./test_superpipe write "plain "
./test_superpipe set_mode upper
./test_superpipe write "CAPS "
./test_superpipe set_mode lower
./test_superpipe write "lower"
./test_superpipe read
# Expected: plain CAPS lower</syntaxhighlight>
'''Test 7: Edge cases'''

<syntaxhighlight lang="bash"># All vowels
./test_superpipe set_mode drop_vowels
./test_superpipe write "aeiou"
./test_superpipe read
# Expected: (empty)

# All spaces
./test_superpipe set_mode drop_spaces
./test_superpipe write " "
./test_superpipe read
# Expected: (empty)</syntaxhighlight>

=== Deliverables ===

Submit a PDF with your code and screenshots of:

* All transform modes tested and working
* Detailed kernel logs


== Reference: Kernel Programming Quick Guide ==


=== Module Macros and Metadata ===

<syntaxhighlight lang="c">#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>

/* Declare init and exit functions */
module_init(my_init_function);
module_exit(my_exit_function);

/* Module metadata (required) */
MODULE_LICENSE("GPL"); /* Must be GPL-compatible */
MODULE_AUTHOR("Your Name <email>");
MODULE_DESCRIPTION("Brief description");
MODULE_VERSION("1.0");

/* Init function signature */
static int __init my_init_function(void)
{
/* Return 0 on success, negative error code on failure */
}

/* Exit function signature */
static void __exit my_exit_function(void)
{
/* No return value */
}</syntaxhighlight>

=== Memory Management ===

<syntaxhighlight lang="c">#include <linux/slab.h>

/* Allocate memory */
void *ptr = kmalloc(size, GFP_KERNEL);
if (!ptr)
return -ENOMEM;

/* Allocate and zero memory */
void *ptr = kzalloc(size, GFP_KERNEL);

/* Free memory */
kfree(ptr);

/* GFP flags:
* GFP_KERNEL - Normal allocation, can sleep
* GFP_ATOMIC - Cannot sleep (use in interrupt context)
* GFP_USER - Allocate for userspace
*/</syntaxhighlight>

=== Data Transfer Functions ===

<syntaxhighlight lang="c">#include <linux/uaccess.h>

/* Copy to userspace */
if (copy_to_user(user_ptr, kernel_ptr, size))
return -EFAULT;

/* Copy from userspace */
if (copy_from_user(kernel_ptr, user_ptr, size))
return -EFAULT;

/* Get a single value from userspace */
int val;
if (get_user(val, (int __user *)user_ptr))
return -EFAULT;

/* Put a single value to userspace */
if (put_user(val, (int __user *)user_ptr))
return -EFAULT;</syntaxhighlight>

=== Synchronization ===

<syntaxhighlight lang="c">#include <linux/mutex.h>

/* Declare mutex */
static DEFINE_MUTEX(my_mutex);

/* Or dynamic initialization */
struct mutex my_mutex;
mutex_init(&my_mutex);

/* Lock (sleeps if unavailable) */
mutex_lock(&my_mutex);
/* ... critical section ... */
mutex_unlock(&my_mutex);

/* Lock (interruptible by signals) */
if (mutex_lock_interruptible(&my_mutex))
return -ERESTARTSYS;
/* ... critical section ... */
mutex_unlock(&my_mutex);

/* Try lock (non-blocking) */
if (mutex_trylock(&my_mutex)) {
/* Got lock */
/* ... critical section ... */
mutex_unlock(&my_mutex);
} else {
/* Lock held by someone else */
}</syntaxhighlight>

=== Logging and Debugging ===

<syntaxhighlight lang="c">#include <linux/kernel.h>

/* Log levels */
printk(KERN_EMERG "Emergency\n"); /* System unusable */
printk(KERN_ALERT "Alert\n"); /* Action must be taken */
printk(KERN_CRIT "Critical\n"); /* Critical condition */
printk(KERN_ERR "Error\n"); /* Error condition */
printk(KERN_WARNING "Warning\n"); /* Warning */
printk(KERN_NOTICE "Notice\n"); /* Normal but significant */
printk(KERN_INFO "Info\n"); /* Informational */
printk(KERN_DEBUG "Debug\n"); /* Debug messages */

/* Formatted output (like printf) */
printk(KERN_INFO "Value: %d, String: %s\n", value, string);

/* Access current process info */
printk(KERN_INFO "PID: %d, Name: %s\n", current->pid, current->comm);

/* View logs */
/* dmesg */
/* tail -f /var/log/kern.log */</syntaxhighlight>

=== Common Error Codes ===

<syntaxhighlight lang="c">#include <linux/errno.h>

return 0; /* Success */
return -ENOMEM; /* Out of memory */
return -EFAULT; /* Bad address (copy_to/from_user failed) */
return -EINVAL; /* Invalid argument */
return -ENOSPC; /* No space left on device */
return -EBUSY; /* Device or resource busy */
return -EIO; /* I/O error */
return -ENODEV; /* No such device */
return -EPERM; /* Operation not permitted */
return -EACCES; /* Permission denied */
return -ERESTARTSYS; /* Interrupted system call */</syntaxhighlight>

== Common Issues and Troubleshooting ==


=== Compilation Errors ===

'''Issue: "No rule to make target"'''

<pre>make: *** No rule to make target 'modules'. Stop.</pre>
'''Cause:''' Wrong KDIR path in Makefile

'''Fix:''' Verify kernel headers are installed and path is correct:

<syntaxhighlight lang="bash">ls -l /lib/modules/$(uname -r)/build
# Should exist and link to kernel source</syntaxhighlight>
'''Issue: "missing MODULE_LICENSE"'''

<pre>WARNING: modpost: missing MODULE_LICENSE() in ...</pre>
'''Cause:''' Forgot to add MODULE_LICENSE macro

'''Fix:''' Add to your module:

<syntaxhighlight lang="c">MODULE_LICENSE("GPL");</syntaxhighlight>
'''Issue: "implicit declaration of function"'''

'''Cause:''' Missing <code>#include</code> directive

'''Fix:''' Add appropriate header. Common headers:

* <code><linux/kernel.h></code> - Core kernel functions
* <code><linux/uaccess.h></code> - copy_to_user, copy_from_user
* <code><linux/slab.h></code> - kmalloc, kfree
* <code><linux/mutex.h></code> - Mutex functions


=== Module Loading Issues ===

'''Issue: "Invalid module format"'''

<pre>insmod: ERROR: could not insert module: Invalid module format</pre>
'''Cause:''' Module compiled for different kernel version

'''Fix:''' Clean and rebuild:

<syntaxhighlight lang="bash">make clean
make</syntaxhighlight>
Ensure <code>uname -r</code> matches the kernel you're running.

'''Issue: "Operation not permitted"'''

'''Cause:''' Need root privileges

'''Fix:''' Use sudo:

<syntaxhighlight lang="bash">sudo insmod module.ko</syntaxhighlight>
'''Issue: "Device or resource busy"'''

<pre>rmmod: ERROR: Module is in use</pre>
'''Cause:''' Device is still open or module is in use

'''Fix:''' Close all programs using the device:

<syntaxhighlight lang="bash">lsof /dev/superpipe # Find processes using device
kill <PID> # Kill processes if necessary
sudo rmmod module</syntaxhighlight>

=== Runtime Issues ===

'''Issue: "Bad address" (-EFAULT) from read/write'''

'''Cause:''' Forgot copy_to_user/copy_from_user

'''Fix:''' Never directly access user pointers:

<syntaxhighlight lang="c">/* WRONG */
strcpy(user_buffer, kernel_data);

/* CORRECT */
if (copy_to_user(user_buffer, kernel_data, len))
return -EFAULT;</syntaxhighlight>
'''Issue: Kernel panic on module load'''

'''Cause:''' Accessing NULL pointer or uninitialized memory

'''Fix:''' Always check return values:

<syntaxhighlight lang="c">buffer = kmalloc(size, GFP_KERNEL);
if (!buffer) {
printk(KERN_ERR "Failed to allocate\n");
return -ENOMEM; /* Don't continue with NULL pointer! */
}</syntaxhighlight>
'''Issue: Data corruption with concurrent access'''

'''Cause:''' Missing mutex locks

'''Fix:''' Protect all shared data:

<syntaxhighlight lang="c">/* Acquire lock before accessing shared state */
mutex_lock_interruptible(&dev_state.lock);

/* Access shared data */

/* Release lock */
mutex_unlock(&dev_state.lock);</syntaxhighlight>
'''Issue: Module stuck, can't unload'''

'''Cause:''' Process stuck in kernel code (infinite loop or deadlock)

'''Fix:'''

* Kill the hung process
* If that doesn't work, reboot (this is why VMs are recommended!)


=== Debugging Strategies ===

'''Strategy 1: Liberally use printk'''

<syntaxhighlight lang="c">printk(KERN_DEBUG "Entering function, buffer_len=%zu\n", dev_state.buffer_len);
printk(KERN_DEBUG "After copy, to_write=%zu\n", to_write);
printk(KERN_DEBUG "Exiting function, returning %zd\n", ret);</syntaxhighlight>
'''Strategy 2: Check return values'''

<syntaxhighlight lang="c">ret = copy_from_user(...);
printk(KERN_DEBUG "copy_from_user returned %lu\n", ret);
if (ret) {
printk(KERN_ERR "Failed to copy %lu bytes\n", ret);
return -EFAULT;
}</syntaxhighlight>
'''Strategy 3: Dump buffer contents'''

<syntaxhighlight lang="c">/* Hexdump helper */
void hexdump(const char *data, size_t len)
{
size_t i;
printk(KERN_DEBUG "Hexdump (%zu bytes):\n", len);
for (i = 0; i < len; i++) {
printk(KERN_CONT "%02x ", (unsigned char)data[i]);
if ((i + 1) % 16 == 0)
printk(KERN_CONT "\n");
}
printk(KERN_CONT "\n");
}</syntaxhighlight>
'''Strategy 4: Monitor kernel logs in real-time'''

In one terminal:

<syntaxhighlight lang="bash">sudo dmesg -w</syntaxhighlight>
In another terminal, run your tests. You'll see kernel messages appear immediately.

'''Strategy 5: Add assertions'''

<syntaxhighlight lang="c">#define ASSERT(cond) \
do { \
if (!(cond)) { \
printk(KERN_ERR "Assertion failed: %s\n", #cond); \
BUG(); \
} \
} while (0)

ASSERT(buffer_len <= BUFFER_SIZE);
ASSERT(mode < TRANSFORM_MAX);</syntaxhighlight>
'''Note:''' <code>BUG()</code> causes a kernel oops. Use only for debugging, remove before submission.


== For Further Study ==


=== Advanced Topics ===

'''1. Multiple Device Instances'''

Extend superpipe to support multiple independent devices (<code>/dev/superpipe0</code>, <code>/dev/superpipe1</code>, etc.) with separate buffers and modes.

'''Hint:''' Use dynamic miscdevice allocation and embed miscdevice in device structure.

'''2. Per-File-Descriptor State'''

Allow each open() to have independent buffer and transformation mode using <code>file->private_data</code>.

'''3. Non-Blocking I/O and Poll'''

Implement <code>O_NONBLOCK</code> support and <code>poll()</code> operation so userspace can use <code>select()</code> or <code>epoll()</code>.

'''4. Sysfs Interface'''

Expose device statistics via sysfs (<code>/sys/class/misc/superpipe/</code>):

* Total bytes read
* Total bytes written
* Current mode
* Buffer usage

'''5. Advanced Transformations'''

Implement more complex transformations:

* ROT13 cipher
* Base64 encoding/decoding
* Compression (simple run-length encoding)

'''6. Ring Buffer Implementation'''

Replace linear buffer with circular ring buffer for better performance (no memmove on read).


=== Relevant Documentation ===

'''Kernel Documentation:'''

<syntaxhighlight lang="bash"># View kernel documentation
cd /usr/src/linux-headers-$(uname -r)
ls Documentation/

# Useful sections:
# - kernel-hacking/
# - driver-api/
# - core-api/</syntaxhighlight>
'''Online Resources:'''

* '''Linux Kernel Documentation:''' https://www.kernel.org/doc/html/latest/
* '''Linux Device Drivers (LDD3):''' Classic book, available online
* '''Kernel Newbies:''' https://kernelnewbies.org/
* '''KernelCI:''' https://kernelci.org/
* '''LKML Archives:''' https://lkml.org/
* '''Bootlin Linux Source View:''' https://elixir.bootlin.com/linux

'''Manual pages:'''

<syntaxhighlight lang="bash">man 2 open # open() system call
man 2 read # read() system call
man 2 write # write() system call
man 2 ioctl # ioctl() system call
man 7 capabilities # Linux capabilities</syntaxhighlight>
'''Kernel source as reference:'''

<syntaxhighlight lang="bash"># Find examples of miscdevice usage
cd /usr/src/linux-source-*/
grep -r "misc_register" drivers/

# Example drivers to study:
# - drivers/char/mem.c (/dev/null, /dev/zero, /dev/random)
# - drivers/char/misc.c (miscdevice framework itself)</syntaxhighlight>
'''Debugging:'''

* <code>addr2line</code>: Convert addresses in oops messages to source lines
* <code>objdump</code>: Disassemble kernel modules
* <code>gdb</code> with <code>/proc/kcore</code>: Debug live kernel
* <code>SystemTap</code> / <code>eBPF</code>: Dynamic kernel tracing

'''Remember:''' The Linux kernel is one of the largest open-source projects. Reading kernel code is the best way to learn kernel programming.

Operating Systems

2025-12-19T14:41:43Z

Vserbu: /* Lab Sessions */

== Lab Sessions ==

* Lab 1 - [[OS Lab 1 - Installing Linux]]
* Lab 2 - [[OS Lab 2 - Linux Filesystems]]
* Lab 3 - [[OS Lab 3 - Processes and Jobs]]
* Lab 4 - [[OS Lab 4 - Users, Groups and Permissions]]
* Lab 5 - [[OS Lab 5 - Bash Scripting]]
* Lab 6 - [[OS Lab 6 - Inter Process Communication]]
* Lab 7 - [[OS Lab 7 - The Network Subsystem]]
* Lab 8 - [[OS Lab 8 - Transport and Security]]
* Lab 9 - [[OS Lab 9 - Application Protocols: DNS, SSH, HTTP(S)]]
* Lab 10 - [[OS Lab 10 - Containers and Docker]]
* Lab 11 - [[OS Lab 11 - Linux Kernel Modules]]

Operating Systems

2025-12-19T14:41:29Z

Vserbu: /* Lab Sessions */

OS Lab 9 - Application Protocols: DNS, SSH, HTTP(S)

2025-12-16T17:01:41Z

Vserbu: /* Part 1: Verifying SSH Installation */

== Objectives ==

Upon completion of this lab, you will be able to:

* Understand core internet infrastructure: well-known ports, DNS hierarchy, and the roles of authoritative vs. recursive DNS servers.
* Use DNS tools (<code>dig</code>, <code>nslookup</code>, <code>host</code>) to query records and analyze responses, including TTLs and caching behavior.
* Configure secure SSH access using Ed25519 keys and explain SSH’s TOFU model compared with certificate-based PKI.
* Build and route HTTP(S) services using a reverse proxy, and understand why this pattern underlies modern cloud architectures.
* Diagnose common application-layer connectivity issues using protocol-specific debugging techniques.


== Introduction ==


=== The Journey Through the Network Stack ===

In Labs 7 and 8, we systematically constructed the entire networking stack from the physical layer upward:

* '''Lab 7 (Network Infrastructure)''': We built the foundational plumbing—network interfaces, MAC addresses, IP addressing, routing tables, network bridges, and the mechanisms that allow one machine to physically reach another across networks. We demonstrated how the kernel routes packets from source to destination based on Ethernet and Layer 3 IP addressing.
* '''Lab 8 (Transport and Security)''': We ascended to the transport layer, introducing the critical concept of '''ports''' to enable process-to-process communication. We explored the fundamental trade-offs between UDP's connectionless simplicity and TCP's reliable, connection-oriented delivery. Most importantly, we implemented Transport Layer Security (TLS) using Public Key Infrastructure (PKI) to protect data in transit from eavesdropping and tampering.

We now reach the pinnacle of the network stack: called the Application Layer in the TCP/IP model. This is where protocols transition from answering "how do we reliably deliver data between processes?" to addressing "what should we do with this data and how should applications interact?"


=== The Application Layer ===

Consider what you actually accomplish with computers in daily practice. You do not consciously think about TCP sequence numbers, IP routing algorithms, or TLS cipher suites. Instead, you engage in high-level activities:

* You type a domain name (e.g., "example.com") and a website appears instantaneously (DNS + HTTP)
* You connect to a remote server to execute commands securely (SSH)
* You upload files, stream videos, send API requests, interact with cloud services (predominantly HTTP/HTTPS)

The application layer is where networking infrastructure becomes visible as useful services. These are the protocols that system administrators, DevOps engineers, and software developers interact with constantly. While hundreds of application protocols exist, three protocols dominate modern networking:

# '''DNS (Port 53)''': The distributed directory service that answers "How do I find the IP address for this domain name?"
# '''SSH (Port 22)''': The secure remote access protocol that answers "How do I securely administer remote systems?"
# '''HTTP/HTTPS (Ports 80/443)''': The hypertext transfer protocol that has evolved far beyond web browsing to become the answer to "How do I communicate application data?" for nearly everything.


=== The Complete Network Request Journey ===

By the end of this lab, you will understand the complete, end-to-end journey of a modern web request. When you type <code>https://api.example.com/users</code> into your browser, the following sequence occurs:

# '''DNS Resolution (This lab)''': Your system queries DNS to resolve <code>api.example.com</code> to an IP address (e.g., 203.0.113.50)
# '''Routing (Lab 7)''': The kernel consults routing tables to determine the next hop toward that IP address
# '''TCP Connection (Lab 8)''': Your system establishes a three-way handshake to create a reliable TCP connection to port 443 at that IP address
# '''TLS Handshake (Lab 8)''': The client and server perform a TLS handshake, establishing an encrypted tunnel using certificates to verify the server's identity
# '''HTTP Request (This lab)''': Your browser sends an HTTP GET request to the <code>/users</code> path over the encrypted connection
# '''Reverse Proxy Routing (This lab)''': A reverse proxy on the server side examines the request path and routes it to the appropriate backend service
# '''Response Journey''': The response flows back through all these layers—HTTP response, TLS encryption, TCP segments, IP packets, Ethernet frames—until it reaches your browser


== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console.

'''Network Topology''': This lab builds upon the network namespace topology established in Lab 8. You should have:

* '''Red namespace''': Simulated host with IP address 10.0.0.1/24
* '''Blue namespace''': Simulated host with IP address 10.0.0.2/24
* '''Host system''': Bridge interface (br0) connecting the namespaces
* Full bidirectional connectivity verified in Lab 8

If you did not complete Lab 8 or your topology has been reset, you will need to recreate it following Lab 8's setup instructions before proceeding.


=== Required Packages ===

The following packages must be installed. Run these commands on your host system:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y openssh-server openssh-client dnsutils bind9-dnsutils \
caddy curl net-tools</syntaxhighlight>
Package descriptions:

* <code>openssh-server</code>: OpenSSH server daemon for accepting SSH connections
* <code>openssh-client</code>: OpenSSH client tools (ssh, scp, sftp) for initiating connections
* <code>dnsutils</code>: DNS client utilities including <code>dig</code> and <code>nslookup</code>
* <code>bind9-dnsutils</code>: Additional DNS diagnostic tools including <code>host</code>
* <code>caddy</code>: Modern web server with automatic HTTPS and simple configuration syntax
* <code>curl</code>: Command-line HTTP client for testing and debugging
* <code>net-tools</code>: Legacy networking tools (netstat, ifconfig) for compatibility


=== Knowledge Prerequisites ===

You should be familiar with:

'''From Lab 7 (Network Fundamentals)''':

* Network interfaces, IP addresses, subnet masks, and CIDR notation
* Routing tables and default gateways
* Network namespaces and virtual ethernet pairs
* Bridge devices and how they connect network segments

'''From Lab 8 (Transport and Security)''':

* TCP and UDP transport protocols
* Port numbers and socket addresses (IP:PORT)
* TLS encryption and certificate-based authentication
* The Public Key Infrastructure (PKI) trust model
* Basic hostname resolution using <code>/etc/hosts</code>

'''General Linux Skills''':

* Command-line text manipulation (grep, awk, sed, cut)
* Process management (starting, stopping, viewing processes)
* File editing with text editors (nano, vim, or your preference)
* Basic Bash scripting (variables, loops, conditionals)

You should also understand:

* The client-server model of network communication
* What an IP address represents and how packets are routed between networks
* The concept of a socket as the combination of IP address and port number
* Basic cryptographic concepts (public/private keys, certificates)


== Theoretical Background ==


=== The Transport Layer Recap ===

Before diving into application protocols, let us briefly revisit why the transport layer exists and what problem it solves. This context is essential for understanding well-known ports and application protocol design.

'''The Fundamental Problem''': An IP address identifies a machine on the network, but machines do not communicate with machines. '''Processes''' (running programs) communicate with processes. When a packet arrives at your machine's IP address, the kernel must determine which of potentially hundreds of running processes should receive that packet.

'''The Solution''': The transport layer introduces '''port numbers'''—16-bit unsigned integers (range 0-65535) that identify specific communication endpoints. When combined with an IP address, a port creates a unique '''socket address''' (written as IP:PORT, e.g., 192.168.1.50:443) that identifies a specific process on a specific machine.

A complete connection is identified by a '''five-tuple''':

# Source IP address
# Source port
# Destination IP address
# Destination port
# Protocol (TCP or UDP)

This five-tuple uniquely identifies a communication channel. For example:

* Client: 192.168.1.50:54321 → Server: 203.0.113.10:443 (HTTPS connection)
* Client: 10.0.0.1:35678 → Server: 10.0.0.2:22 (SSH connection)

With this foundation established, we can now explore how standardized port numbers enable service discovery at internet scale.


=== Well-Known Ports ===


==== The Problem: Service Discovery Without Coordination ====

Consider a scenario where you want to connect to a web server running at IP address <code>10.0.0.3</code>. You know the machine's network address, but you face a critical problem: '''Which port is the web server listening on?'''

The server could be bound to any of 65,535 possible port numbers:

* Port 80? (Traditional HTTP)
* Port 8080? (Alternative HTTP)
* Port 3000? (Common development port)
* Port 9000? (Arbitrary choice)
* Some completely random port like 47281?

Without knowing the correct port, you cannot establish a connection. It is analogous to knowing someone's street address but not their apartment number in a massive building with 65,535 apartments.

You could attempt to connect to all 65,535 ports sequentially (this is precisely what port scanning tools like <code>nmap</code> do), but this approach is:

* Extremely slow (trying all ports could take minutes or hours)
* Inefficient (wastes network bandwidth and computational resources)
* Potentially suspicious (may trigger intrusion detection systems)
* Impractical for everyday use (users expect instant connections)

There must be a superior solution.


==== The Solution: Standardized Port Assignments ====

The early architects of the internet solved this problem through an elegantly simple mechanism: '''social convention'''. The Internet Assigned Numbers Authority (IANA) maintains an official registry of port number assignments, and the community agrees to follow these standards.

This is not a technical enforcement mechanism—there is no kernel code that prevents you from running an SSH server on port 8080 or an HTTP server on port 22. Instead, it is a '''social contract''': we collectively agree that certain services will use certain ports, making the internet predictable and functional.


==== Port Number Space Division ====

The IANA divides the port number space into three categories:

'''1. Well-Known Ports (0-1023)'''

These ports are reserved for standard, widely-used services. Key characteristics:

* Officially registered with IANA for specific protocols
* Binding to these ports requires elevated privileges (root/administrator) on Unix-like systems
* This privilege requirement is a security feature: it prevents normal users from impersonating critical services
* Examples: HTTP (80), HTTPS (443), SSH (22), DNS (53), SMTP (25)

The privilege requirement exists because if any user could bind to port 80, they could impersonate a web server and potentially trick other programs or users into trusting them.

'''2. Registered Ports (1024-49151)'''

These ports can be registered with IANA for specific services, but enforcement is less strict. Characteristics:

* No special privileges required to bind
* Software vendors often register ports for their applications
* Examples: MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379)
* Applications can use these ports without requiring root access

'''3. Dynamic/Private/Ephemeral Ports (49152-65535)'''

These ports are used for temporary client-side connections. Characteristics:

* Never registered for permanent services
* Assigned automatically by the operating system when a client initiates an outbound connection
* The client doesn't choose these ports explicitly
* Used briefly for the duration of a connection, then released back to the pool

When your web browser connects to a server, it might use local address <code>192.168.1.50:52341</code> (your machine + random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server + standard HTTPS port).


==== The Social Contract in Practice ====

When a server administrator configures a service, they '''listen on the well-known port''' for that service type. Clients, in turn, '''assume''' servers use these standard ports. This mutual agreement eliminates the need for explicit coordination.

'''Example 1: SSH Connection'''

When you execute:

<syntaxhighlight lang="bash">ssh admin@server.example.com</syntaxhighlight>
The SSH client automatically attempts to connect to port 22. You do not need to specify the port. The client assumes the server follows the convention. Under the hood, this command is equivalent to:

<syntaxhighlight lang="bash">ssh -p 22 admin@server.example.com</syntaxhighlight>
The <code>-p 22</code> is implicit because port 22 is the well-known port for SSH.

'''Example 2: Web Browsing'''

When you enter a URL in your browser:

<pre>http://example.com</pre>
Your browser automatically connects to port 80. Similarly, for:

<pre>https://example.com</pre>
Your browser connects to port 443. These behaviors are hardcoded into HTTP client software based on the URL scheme.

'''Breaking the Convention'''

You are not technically required to follow these conventions. You can run an SSH server on port 8022, a web server on port 3000, or DNS on port 5353. However, breaking conventions creates friction—clients need explicit instructions:

<syntaxhighlight lang="bash"># Non-standard SSH port requires explicit specification
ssh -p 8022 admin@server.example.com

# Non-standard HTTP port must be included in URL
curl http://example.com:3000</syntaxhighlight>
'''Analogy''': Well-known ports function like standardized electrical outlets. In Europe, you expect 220V AC outlets with a specific two-prong configuration. You can plug in any device without checking each outlet—you trust the convention. Similarly, you can connect to any SSH server without checking its port—you trust it will be on port 22.

'''Critical Ports'''

As a system administrator or developer, you will usually interact with these port numbers:

* '''Port 20/21''': FTP (File Transfer Protocol) - Legacy, rarely used today
* '''Port 22''': SSH (Secure Shell) - Remote system access
* '''Port 23''': Telnet - Legacy insecure remote access (NEVER USE)
* '''Port 25''': SMTP (Simple Mail Transfer Protocol) - Email sending
* '''Port 53''': DNS (Domain Name System) - Name resolution
* '''Port 80''': HTTP (Hypertext Transfer Protocol) - Web traffic unencrypted
* '''Port 110''': POP3 (Post Office Protocol) - Email retrieval (legacy)
* '''Port 143''': IMAP (Internet Message Access Protocol) - Modern email retrieval
* '''Port 443''': HTTPS (HTTP Secure) - Encrypted web traffic
* '''Port 3306''': MySQL database server
* '''Port 5432''': PostgreSQL database server
* '''Port 6379''': Redis in-memory database
* '''Port 8080''': Alternative HTTP port (often used for development)

This social contract—standardized port numbers—is a foundational element that makes the internet function at global scale. It exemplifies how simple conventions can solve complex coordination problems.


=== Domain Name System (DNS) ===

The human-computer impedance mismatch is a fundamental challenge in computing: humans prefer memorable, meaningful names, while computers require numerical addresses. The Domain Name System (DNS) bridges this gap by providing a distributed, hierarchical database that maps human-readable domain names to machine-usable IP addresses (and other information).


==== Human Memory vs. Computer Addressing ====

IP addresses are the actual addressing mechanism for network communication. When your computer needs to send packets to a destination, it must know that destination's IP address. However, IP addresses present several problems for human users:

'''1. Memorization Difficulty'''

IPv4 addresses like <code>172.217.14.206</code> are difficult for humans to remember and type accurately. IPv6 addresses like <code>2607:f8b0:4004:c07::64</code> are even worse. While you might remember your own phone number, remembering hundreds of IP addresses for services you use is impractical.

'''2. Instability and Change'''

IP addresses can change due to:

* Infrastructure migrations (moving servers between data centers)
* Load balancing requirements (distributing traffic across multiple servers)
* Failover scenarios (switching to backup servers during outages)
* Dynamic allocation (DHCP assigns different IPs over time)

If users memorized IP addresses, every infrastructure change would break their connections.

'''3. Lack of Semantic Meaning'''

An IP address like <code>198.51.100.42</code> conveys no information about what service it provides or which organization operates it. The name <code>store.example.com</code> immediately suggests it's a commercial store operated by Example Corporation.

'''4. Service Multiplexing'''

A single IP address can host multiple services (using different ports) or multiple websites (using HTTP virtual hosting). The domain name helps identify which specific service the user wants.

The Solution: Domain Name System

DNS solves these problems by creating a globally distributed, hierarchical naming system that maps domain names to IP addresses and other resource records.

'''Historical Context''': Before DNS, the internet used a centralized hosts file (<code>/etc/hosts</code> on Unix systems) maintained by the Network Information Center (NIC) at Stanford Research Institute. Administrators would request IP-to-hostname mappings, and NIC would periodically distribute an updated hosts file to all connected systems. This approach did not scale beyond a few thousand hosts.

In 1983, Paul Mockapetris designed the Domain Name System (RFC 882 and RFC 883, later superseded by RFC 1034 and RFC 1035), which has remained the foundation of internet naming for over 40 years.


==== DNS Hierarchy: Organizing the Global Namespace ====

DNS organizes domain names in a hierarchical tree structure, reading from right to left:

<pre>www.engineering.example.com.
| | | |
| | | └── Root (empty label)
| | └────────── Top-Level Domain (TLD)
| └───────────────────── Second-Level Domain (SLD)
└───────────────────────────── Subdomain(s)</pre>
'''The Root Domain (".")'''

At the top of the hierarchy is the root domain, represented by an empty label. Fully qualified domain names (FQDNs) technically end with a dot: <code>example.com.</code> The trailing dot is usually omitted in practice, but it represents the root.

There are 13 root name server systems (labeled A through M: a.root-servers.net through m.root-servers.net) operated by different organizations worldwide. These are the authoritative source for information about top-level domains.

'''Top-Level Domains (TLDs)'''

TLDs are the highest level of the DNS hierarchy below the root. Categories include:

* '''Generic TLDs (gTLDs)''': .com, .org, .net, .edu, .gov, .mil, .int
* '''Country-Code TLDs (ccTLDs)''': .us (United States), .uk (United Kingdom), .jp (Japan), .de (Germany)
* '''New gTLDs''': .app, .dev, .tech, .cloud, .blog, etc. (thousands added since 2013)

Each TLD is managed by a registry organization. For example, VeriSign operates the .com and .net TLDs, while Educause operates .edu.

'''Second-Level Domains (SLDs)'''

These are the domains that organizations register: <code>example.com</code>, <code>github.com</code>, <code>mit.edu</code>. You register these through domain registrars, who interface with the TLD registries.

'''Subdomains'''

Domain owners can create arbitrary subdomains: <code>www.example.com</code>, <code>mail.example.com</code>, <code>api.v2.example.com</code>. Subdomains do not require separate registration—the owner of the parent domain controls all subdomains.

DNS Servers: Authoritative vs. Recursive

Two fundamentally different types of DNS servers perform distinct roles in the DNS infrastructure:

'''Authoritative DNS Servers'''

Authoritative servers are the definitive source of truth for a specific zone (portion of the DNS namespace). Characteristics:

* '''Responsibility''': Provide answers for domains they have explicit authority over
* '''Data Source''': Return information directly from their configured zone files
* '''Behavior''': Only answer queries for domains in their zones; refer queries elsewhere for other domains
* '''Operation''': Typically operated by domain owners or their DNS providers
* '''Caching''': Do not cache responses for other domains
* '''Example''': If you own <code>example.com</code>, your authoritative servers know the IP addresses for <code>www.example.com</code>, <code>mail.example.com</code>, etc.

When you configure DNS records for your domain through your registrar or DNS provider, you are updating authoritative servers.

'''Recursive DNS Resolvers (Recursive Resolvers)'''

Recursive resolvers perform the DNS resolution process on behalf of clients. Characteristics:

* '''Responsibility''': Answer any DNS query by recursively querying authoritative servers
* '''Data Source''': Cache responses and query authoritative servers when cache misses occur
* '''Behavior''': Accept any query and traverse the DNS hierarchy to find answers
* '''Operation''': Typically provided by ISPs, corporations, or public DNS services (Google Public DNS 8.8.8.8, Cloudflare 1.1.1.1)
* '''Caching''': Extensively cache responses to improve performance and reduce load
* '''Client-Facing''': This is the type of server that end-user devices query

When your computer performs a DNS lookup, it queries a recursive resolver, which then does the work of finding the answer.

'''Critical Distinction'''

This distinction is fundamental:

* '''Authoritative servers''': "I have authority over example.com, and I can definitively tell you that [http://www.example.com www.example.com] is 203.0.113.50"
* '''Recursive resolvers''': "I don't know the answer to your query, but I'll traverse the DNS hierarchy to find an authoritative server that does know, then give you the answer"

'''Analogy''': An authoritative DNS server is like a property owner who knows everything about their own house. A recursive resolver is like a GPS navigation system that can find directions to any address by consulting various maps and data sources.


==== DNS Resolution Process: Following the Hierarchy ====

When you type <code>www.example.com</code> in your browser and press Enter, a complex resolution process occurs behind the scenes. Let us trace this process step by step.

'''Scenario''': Your computer needs to resolve <code>www.example.com</code> to an IP address. Your system is configured to use the recursive resolver at 1.1.1.1 (Cloudflare's public DNS).

'''Step 1: Check Local Cache'''

Your operating system maintains a local DNS cache. If <code>www.example.com</code> was recently resolved and the TTL hasn't expired, the cached answer is returned immediately (typically in microseconds). No network query is needed.

If the cache contains no valid entry, proceed to Step 2.

'''Step 2: Query Recursive Resolver'''

Your computer sends a DNS query to its configured recursive resolver (1.1.1.1):

<pre>Query: What is the IP address for www.example.com?</pre>
The recursive resolver checks its own cache. If it has a recent answer, it returns immediately. If not, it begins the recursive resolution process.

'''Step 3: Query Root Servers'''

The recursive resolver queries one of the 13 root name servers:

<pre>Resolver → Root Server: What is the IP address for www.example.com?</pre>
The root server does not know the specific answer but knows which servers are authoritative for the .com TLD:

<pre>Root → Resolver: I don't know about www.example.com specifically,
but you can ask the .com TLD servers. Here are their addresses:
- a.gtld-servers.net (192.5.6.30)
- b.gtld-servers.net (192.33.14.30)
[and others...]</pre>
This is called a '''referral'''—the root server refers the resolver to servers that are more specific.

'''Step 4: Query TLD Servers'''

The resolver queries one of the .com TLD servers:

<pre>Resolver → .com TLD Server: What is the IP address for www.example.com?</pre>
The TLD server knows which name servers are authoritative for example.com:

<pre>.com TLD → Resolver: I don't know about www.example.com specifically,
but the authoritative servers for example.com are:
- ns1.example.com (198.51.100.1)
- ns2.example.com (198.51.100.2)</pre>
Another referral, this time to the authoritative servers for the domain.

'''Step 5: Query Authoritative Servers'''

The resolver queries example.com's authoritative name server:

<pre>Resolver → ns1.example.com: What is the IP address for www.example.com?</pre>
This server has definitive authority over example.com and provides the answer:

<pre>ns1.example.com → Resolver: www.example.com is 203.0.113.50
(TTL: 3600 seconds)</pre>
'''Step 6: Return Answer to Client'''

The recursive resolver returns the answer to your computer:

<pre>Resolver → Your Computer: www.example.com is 203.0.113.50</pre>
'''Step 7: Cache at Multiple Levels'''

The answer is cached:

* Your operating system caches the result (OS-level cache)
* Your browser may have its own cache (application-level cache)
* The recursive resolver caches the result (resolver cache)

Future queries for <code>www.example.com</code> within the TTL period (3600 seconds = 1 hour in this example) will be answered from cache without repeating the full resolution process.


==== DNS Record Types ====

DNS stores more than just IP addresses. Different record types serve different purposes:

'''A Record (Address Record)'''

Maps a domain name to an IPv4 address.

<pre>www.example.com. IN A 203.0.113.50</pre>
This is the most common record type. When you browse to a website, your browser requests the A record to find the server's IPv4 address.

'''AAAA Record (IPv6 Address Record)'''

Maps a domain name to an IPv6 address.

<pre>www.example.com. IN AAAA 2001:db8::1</pre>
Pronounced "quad-A record." As IPv6 adoption increases, these records are becoming more common.

'''CNAME Record (Canonical Name Record)'''

Creates an alias from one domain name to another. The resolver follows the chain to find the final IP address.

<pre>www.example.com. IN CNAME webserver.example.com.
webserver.example.com. IN A 203.0.113.50</pre>
Use cases:

* Simplifying infrastructure changes (update one A record instead of many)
* Content delivery networks (CDNs): alias your domain to the CDN's domain
* Load balancing and failover scenarios

'''MX Record (Mail Exchanger Record)'''

Specifies the mail servers responsible for receiving email for a domain. Includes a priority number (lower numbers have higher priority).

<pre>example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.</pre>
If mail1 is unavailable, the sending server tries mail2. Email delivery depends critically on properly configured MX records.

'''NS Record (Name Server Record)'''

Specifies the authoritative name servers for a domain or zone.

<pre>example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.</pre>
These records delegate authority. When you register a domain, you specify NS records pointing to your DNS provider's servers.

'''TXT Record (Text Record)'''

Stores arbitrary text data. Modern uses include:

* SPF records for email authentication: <code>"v=spf1 include:_spf.example.com ~all"</code>
* DKIM keys for email signing
* Domain verification for services (Google, Microsoft, etc.): <code>"google-site-verification=abc123xyz789"</code>
* DMARC policies for email protection

Example:

<pre>example.com. IN TXT "v=spf1 include:_spf.google.com ~all"</pre>
'''PTR Record (Pointer Record)'''

Provides reverse DNS lookup—mapping an IP address to a domain name. Used primarily for email server validation and logging.

<pre>50.113.0.203.in-addr.arpa. IN PTR mail.example.com.</pre>
Mail servers often check PTR records to verify sender legitimacy.

'''SOA Record (Start of Authority Record)'''

Defines authoritative information about a DNS zone, including the primary name server, administrator's email, serial number, and timing parameters for zone transfers and caching.

<pre>example.com. IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial
3600 ; Refresh (1 hour)
1800 ; Retry (30 minutes)
1209600 ; Expire (2 weeks)
86400 ; Minimum TTL (1 day)
)</pre>
Time To Live (TTL)

Every DNS record includes a TTL (Time To Live) value specified in seconds. This value tells caching servers how long they can store the record before re-querying the authoritative server.

'''Short TTL (e.g., 60-300 seconds)'''

Advantages:

* Changes propagate quickly
* Useful before planned infrastructure changes
* Allows rapid failover

Disadvantages:

* Increases DNS query load
* Slightly slower for end users (more frequent resolution)
* Higher bandwidth consumption

'''Long TTL (e.g., 3600-86400 seconds)'''

Advantages:

* Reduces DNS query load significantly
* Faster for end users (more cache hits)
* Lower bandwidth consumption
* Better resilience if authoritative servers become unavailable

Disadvantages:

* Changes propagate slowly (users may see old data until TTL expires)
* Failover is slower


=== Secure Shell (SSH): Encrypted Remote Access ===

SSH (Secure Shell) is the standard protocol for secure remote access to systems. It replaced the insecure Telnet protocol in the 1990s and has become ubiquitous in system administration, DevOps, and software development.

SSH provides three critical security properties:

# '''Confidentiality''': All data (including credentials) is encrypted using symmetric encryption (AES, ChaCha20)
# '''Integrity''': Cryptographic MACs (Message Authentication Codes) prevent tampering
# '''Authentication''': Public key cryptography verifies server and optionally client identity


==== SSH Architecture ====

'''SSH is not a single protocol but a protocol suite:'''

# '''SSH-TRANS (Transport Layer Protocol, RFC 4253)''': Establishes encrypted channel, handles server authentication
# '''SSH-AUTH (Authentication Protocol, RFC 4252)''': Handles client authentication (password, public key, etc.)
# '''SSH-CONN (Connection Protocol, RFC 4254)''': Multiplexes multiple channels (terminal session, port forwarding, etc.) over one TCP connection

'''Standard Port''': TCP port 22 (well-known port)

'''Connection Establishment Sequence''':

<pre>1. TCP three-way handshake establishes connection
2. SSH version exchange (both sides advertise SSH protocol version)
3. Algorithm negotiation (agree on encryption, MAC, compression algorithms)
4. Diffie-Hellman key exchange generates session keys
5. Server authenticates itself using its host key
6. Client authenticates itself (password or public key)
7. Encrypted session established, commands can be executed</pre>

==== SSH Authentication Methods ====

SSH supports multiple authentication methods, which can be combined or used exclusively:

'''1. Password Authentication'''

The client sends the password over the encrypted SSH connection (not plaintext like Telnet). While the password is protected in transit, password authentication has weaknesses:

* Vulnerable to brute-force attacks if weak passwords are used
* Requires users to memorize or manage passwords
* Passwords can be stolen through phishing, keyloggers, or social engineering
* No way to distinguish different clients (all use the same password)

'''2. Public Key Authentication (Recommended)'''

Uses asymmetric cryptography:

* Client generates a public/private key pair
* Public key is placed on the server in <code>~/.ssh/authorized_keys</code>
* Private key remains on the client and never leaves the system
* Server challenges client to prove possession of the private key without transmitting it

'''Advantages''':

* Strong cryptographic security (typically 2048-4096 bit RSA or 256 bit Ed25519)
* No password to steal or forget
* Can use different keys for different purposes
* Keys can be protected with passphrases
* Supports automation (keys without passphrases for scripts)

'''Modern Best Practice''': Disable password authentication entirely, allowing only public key authentication.

Public Key Cryptography Review

Since public key authentication is critical to SSH security, let us review the cryptographic foundation:

'''Asymmetric Cryptography Properties''':

# Two mathematically related keys: public key and private key
# Public key can be shared openly
# Private key must be kept secret
# Data encrypted with public key can only be decrypted with private key
# Data signed with private key can be verified with public key

'''SSH Authentication Protocol''':

# Client sends username and public key to server
# Server checks if public key is in <code>~/.ssh/authorized_keys</code> for that user
# Server generates random challenge, encrypts it with client's public key, sends to client
# Client decrypts challenge with private key, computes hash, sends hash back
# Server verifies hash matches expected value
# If match: authentication succeeds (client proved possession of private key)

The private key never travels across the network. The server cannot impersonate the client because it only has the public key.


==== SSH Key Types ====

Modern SSH supports several key types with different security and performance characteristics:

'''RSA (Rivest-Shamir-Adleman)'''

* Traditional and widely supported
* Key size: 2048 or 4096 bits (3072 bits is middle ground)
* Slower than newer algorithms
* Still secure if key size is adequate (≥2048 bits)
* Command: <code>ssh-keygen -t rsa -b 4096</code>

'''Ed25519 (Edwards-curve Digital Signature Algorithm)'''

* Modern elliptic curve algorithm (introduced ~2013)
* Key size: 256 bits (much smaller than RSA)
* Faster than RSA
* Strong security properties
* Command: <code>ssh-keygen -t ed25519</code>

'''ECDSA (Elliptic Curve Digital Signature Algorithm)'''

* Older elliptic curve algorithm
* Key sizes: 256, 384, or 521 bits
* Concerns about NSA influence on NIST curves
* Ed25519 generally preferred over ECDSA for new keys
* Command: <code>ssh-keygen -t ecdsa -b 256</code>

'''Best Practice''': Use Ed25519 for new SSH keys. It offers excellent security with small key sizes and fast performance. Fall back to RSA 4096 only if connecting to older systems that don't support Ed25519.


==== SSH Host Key Verification: Trust On First Use (TOFU) ====

One of SSH's critical security features is host key verification, which protects against man-in-the-middle (MITM) attacks. This mechanism uses a "Trust On First Use" (TOFU) model.

'''The MITM Threat'''

Consider this attack scenario:

<pre>[Your Computer] ←→ [Attacker's Computer] ←→ [Real Server]</pre>
The attacker intercepts your connection, relays your commands to the real server, and relays responses back to you. From your perspective, everything appears normal, but the attacker can:

* Log all your commands and responses
* Steal credentials if you authenticate with passwords
* Modify commands before forwarding them
* Inject malicious commands

This is called a man-in-the-middle (MITM) attack.

'''SSH's Defense: Host Keys'''

Every SSH server has a unique host key (a public/private key pair) that identifies the server. The server's public host key is its cryptographic identity.

When you first connect to a server, SSH shows:

<pre>The authenticity of host 'server.example.com (203.0.113.50)' can't be established.
ED25519 key fingerprint is SHA256:abcd1234efgh5678ijkl9012mnop3456qrst7890uvwx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?</pre>
This is the TOFU moment. SSH is asking: "I've never seen this server before. Do you trust this host key?"

'''If you type "yes"''':

SSH stores the server's host key in <code>~/.ssh/known_hosts</code>:

<pre>server.example.com,203.0.113.50 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
On subsequent connections, SSH verifies the server presents the same host key. If the host key changes, SSH displays an alarming warning:

<pre>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!</pre>
'''Why the Warning?'''

A changed host key indicates one of several scenarios:

# '''Legitimate''': Server was reinstalled, host key regenerated
# '''Legitimate''': Server moved to new hardware
# '''Malicious''': MITM attack in progress
# '''Configuration Error''': Connecting to wrong server

SSH conservatively assumes the worst-case scenario and refuses the connection.

'''The TOFU Model'''

"Trust On First Use" means:

* First connection: You must manually verify the host key (typically by checking a fingerprint through an out-of-band channel)
* Subsequent connections: SSH automatically verifies the host key matches the stored value

'''Comparison to PKI (Lab 8)'''

Recall from Lab 8 that TLS uses a Public Key Infrastructure (PKI) with Certificate Authorities (CAs). Let us contrast the two models:

'''PKI/CA Model (HTTPS/TLS)''':

* Server presents a certificate signed by a trusted CA
* Your browser has a list of trusted CA public keys
* Browser verifies certificate signature cryptographically
* No manual verification needed on first connection
* Scales well: one CA can sign millions of certificates

'''TOFU Model (SSH)''':

* Server presents its public host key
* No centrally trusted authority
* You must manually verify on first connection (or accept risk)
* Subsequent connections are automatically verified
* Simpler infrastructure, but first-use verification is user's responsibility

'''Why SSH Uses TOFU Instead of PKI''':

# SSH predates widespread PKI adoption
# No consensus on which CAs to trust for SSH
# PKI adds complexity and cost (certificate purchase/management)
# TOFU works well for SSH's primary use case (administrators connecting to their own servers)
# SSH certificates exist but are less common than HTTPS certificates

'''Best Practice''': On first connection, verify the host key fingerprint through a trusted channel:

* Check the fingerprint displayed in server documentation
* View the fingerprint on the server directly: <code>ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub</code>
* Compare with fingerprint shown by SSH client

For production systems, always verify host keys. For test/lab environments, the risk is lower.


==== SSH Known Hosts Format ====

The <code>~/.ssh/known_hosts</code> file stores server host keys. Format:

<pre>hostname,ip algorithm public_key</pre>
Example:

<pre>server.example.com,203.0.113.50 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
'''Hashed Format''': Some systems hash the hostname for privacy:

<pre>|1|base64hash|base64hash ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
This prevents someone with access to your known_hosts file from learning which servers you connect to.

'''Wildcard Entries''': You can use wildcards:

<pre>*.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
'''Management''': Remove entries when servers are legitimately reinstalled:

<syntaxhighlight lang="bash">ssh-keygen -R server.example.com</syntaxhighlight>

==== SSH Authorized Keys ====

The <code>~/.ssh/authorized_keys</code> file on the server determines which public keys can authenticate as a specific user.

'''Format''': One public key per line:

<pre>ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIdef456... user@laptop
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCghi789... user@desktop</pre>
The trailing comment (<code>user@laptop</code>) is optional but helps identify keys.

'''Permissions''': SSH is strict about file permissions for security:

<syntaxhighlight lang="bash">chmod 700 ~/.ssh # Directory: rwx------
chmod 600 ~/.ssh/authorized_keys # File: rw-------</syntaxhighlight>
If permissions are too permissive, SSH may refuse to use the keys.

'''Restricting Keys''': You can add restrictions before keys:

<pre>command="backup.sh" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIdef456... backup-key
from="203.0.113.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIghi789... admin-key</pre>
* <code>command="backup.sh"</code>: This key can only run backup.sh (useful for automation)
* <code>from="203.0.113.0/24"</code>: This key only works from specified IP range

'''SSH Agent''': For convenience, use ssh-agent to cache decrypted private keys:

<syntaxhighlight lang="bash">eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519</syntaxhighlight>
The agent holds the unlocked private key in memory, allowing multiple connections without re-entering the passphrase.


=== HyperText Transfer Protocol (HTTP): The Universal Application Protocol ===

HTTP (HyperText Transfer Protocol) was initially designed in 1991 by Tim Berners-Lee to transfer hypertext documents (HTML web pages). Over three decades, HTTP has evolved far beyond its original purpose to become the universal protocol for nearly all application-level communication on the internet.


==== Why HTTP is Everywhere ====

'''1. Simplicity'''

HTTP uses human-readable text commands:

<pre>GET /api/users HTTP/1.1
Host: api.example.com</pre>
This simplicity makes HTTP easy to:

* Debug (you can read the protocol)
* Implement (libraries exist for every language)
* Extend (add custom headers easily)

'''2. Statelessness'''

Each HTTP request is independent—the server doesn't need to maintain state between requests. This design decision has profound implications:

* Servers can handle millions of clients without per-client memory
* Horizontal scaling is trivial (add more servers, any server can handle any request)
* Failures don't cascade (if a request fails, retry without state recovery)
* Caching is straightforward (each request is independent)

State management, when needed, is handled at the application layer (cookies, sessions, tokens).

'''3. Flexible Content'''

HTTP can transfer any type of data:

* HTML documents
* JSON API responses
* XML data
* Binary files (images, videos, executables)
* Streaming data

The <code>Content-Type</code> header specifies what the body contains:

<pre>Content-Type: application/json
Content-Type: text/html
Content-Type: image/png</pre>
'''4. Firewall Friendliness'''

HTTP (port 80) and HTTPS (port 443) are almost universally allowed through firewalls. Companies may block many ports, but they cannot block web traffic without breaking internet access. Applications using HTTP/HTTPS thus avoid firewall issues that plague custom protocols.

'''5. Tooling and Infrastructure'''

Decades of investment have created rich ecosystems:

* Web servers: Apache, Nginx, Caddy, IIS
* Reverse proxies and load balancers
* CDNs (Content Delivery Networks)
* Caching proxies
* API gateways
* Monitoring and debugging tools

'''The Result''': HTTP has become the default choice for application communication. APIs that might have used custom TCP protocols now use HTTP-based REST or GraphQL. Real-time protocols that might have used custom UDP protocols now use WebSockets (which upgrade HTTP connections). Even protocols that don't naturally map to HTTP often use it anyway for operational simplicity.

HTTP Request-Response Model

HTTP uses a simple request-response pattern:

'''Client sends HTTP Request''':

<pre>METHOD PATH VERSION
Headers
(blank line)
Body (optional)</pre>
'''Server sends HTTP Response''':

<pre>VERSION STATUS_CODE STATUS_MESSAGE
Headers
(blank line)
Body (optional)</pre>
'''Example Exchange''':

Request:

<syntaxhighlight lang="http">GET /api/users/123 HTTP/1.1
Host: api.example.com
User-Agent: curl/7.68.0
Accept: application/json</syntaxhighlight>
Response:

<syntaxhighlight lang="http">HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 58

{"id":123,"name":"Alice","email":"alice@example.com"}</syntaxhighlight>

==== HTTP Methods (Verbs) ====

HTTP defines several methods that indicate the desired action:

'''GET''': Retrieve a resource

* Should not modify server state (idempotent and safe)
* Can be cached
* Examples: Load web page, fetch API data, download file

'''POST''': Submit data to create a new resource

* May modify server state
* Not idempotent (repeating creates multiple resources)
* Examples: Submit form, create new user via API

'''PUT''': Update an existing resource (or create if doesn't exist)

* Idempotent (repeating has same effect as doing once)
* Replaces entire resource
* Examples: Update user profile, upload file

'''PATCH''': Partially update a resource

* Apply partial modifications
* Not necessarily idempotent (depends on implementation)
* Examples: Update single field of a record

'''DELETE''': Remove a resource

* Idempotent (deleting twice has same effect as deleting once)
* Examples: Delete user account, remove file

'''HEAD''': Same as GET but returns only headers (no body)

* Check if resource exists
* Check content size before downloading
* Verify cache freshness

'''OPTIONS''': Query supported methods for a resource

* Used for CORS (Cross-Origin Resource Sharing) preflight requests


==== HTTP Status Codes ====

The status code indicates the result of the request. Codes are grouped:

'''1xx: Informational'''

* 100 Continue: Client should continue with request
* 101 Switching Protocols: Server switching protocols (e.g., WebSocket upgrade)

'''2xx: Success'''

* 200 OK: Request succeeded
* 201 Created: Resource created successfully
* 204 No Content: Success but no response body

'''3xx: Redirection'''

* 301 Moved Permanently: Resource moved, update bookmarks
* 302 Found: Temporary redirect
* 304 Not Modified: Cached version is still valid

'''4xx: Client Error'''

* 400 Bad Request: Malformed request
* 401 Unauthorized: Authentication required
* 403 Forbidden: Authenticated but not authorized
* 404 Not Found: Resource doesn't exist
* 429 Too Many Requests: Rate limit exceeded

'''5xx: Server Error'''

* 500 Internal Server Error: Server encountered error
* 502 Bad Gateway: Proxy received invalid response from upstream
* 503 Service Unavailable: Server temporarily overloaded or down
* 504 Gateway Timeout: Proxy timeout waiting for upstream


==== HTTP Headers ====

Headers provide metadata about the request or response. Some critical headers:

'''Request Headers''':

* <code>Host: api.example.com</code> — Required in HTTP/1.1, specifies target hostname
* <code>User-Agent: curl/7.68.0</code> — Identifies client software
* <code>Accept: application/json</code> — Content types client understands
* <code>Authorization: Bearer token123</code> — Authentication credentials
* <code>Content-Type: application/json</code> — Type of request body
* <code>Content-Length: 58</code> — Size of request body in bytes

'''Response Headers''':

* <code>Content-Type: application/json</code> — Type of response body
* <code>Content-Length: 1234</code> — Size of response body
* <code>Cache-Control: max-age=3600</code> — Caching directives
* <code>Set-Cookie: session=abc123; HttpOnly</code> — Set cookie in browser
* <code>Location: /api/users/456</code> — Redirect target (with 3xx status)
* <code>Server: nginx/1.18.0</code> — Server software (often hidden for security)

'''Security Headers''' (modern best practices):

* <code>Strict-Transport-Security: max-age=31536000</code> — Force HTTPS
* <code>Content-Security-Policy: default-src 'self'</code> — Mitigate XSS attacks
* <code>X-Frame-Options: DENY</code> — Prevent clickjacking


==== Virtual Hosting: Multiple Sites on One IP ====

HTTP's <code>Host</code> header enables virtual hosting—running multiple websites on a single IP address. The web server examines the <code>Host</code> header to determine which site the request targets:

<syntaxhighlight lang="http">GET / HTTP/1.1
Host: site1.example.com</syntaxhighlight>
vs.

<syntaxhighlight lang="http">GET / HTTP/1.1
Host: site2.example.com</syntaxhighlight>
Both requests go to the same IP address (e.g., 203.0.113.50) and same port (80 or 443), but the <code>Host</code> header tells the server which site to serve. This is how shared hosting providers can host thousands of websites on relatively few servers.

'''HTTPS Complication''': Virtual hosting works seamlessly for HTTP, but HTTPS initially had issues because the TLS handshake occurs before the HTTP request (so the server doesn't know which certificate to present). Server Name Indication (SNI), added to TLS in 2003, solved this by including the hostname in the TLS handshake.


==== HTTP/1.1 vs. HTTP/2 vs. HTTP/3 ====

'''HTTP/1.1''' (1997, RFC 2616, updated RFC 7230-7235):

* Text-based protocol
* One request per connection (or serial requests with keep-alive)
* Head-of-line blocking (one slow request delays all subsequent requests)
* Still widely used

'''HTTP/2''' (2015, RFC 7540):

* Binary protocol (more efficient parsing)
* Multiplexing (multiple concurrent requests on one connection)
* Server push (server can send resources before client requests them)
* Header compression (reduces overhead)
* Requires HTTPS in practice (browsers only support HTTP/2 over TLS)
* Growing adoption

'''HTTP/3''' (2022, RFC 9114):

* Uses QUIC instead of TCP (UDP-based transport with built-in TLS)
* Reduces connection establishment latency
* Better handling of packet loss
* Connection migration (survive IP address changes)
* Newest, increasing adoption

For this lab, we use HTTP/1.1 for simplicity, but modern production systems increasingly deploy HTTP/2 and HTTP/3.

Reverse Proxies: The Modern Web Architecture Pattern

A reverse proxy is a server that sits in front of backend servers and forwards client requests to them. The client believes it is talking directly to the origin server, unaware of the proxy's existence.

'''Terminology Clarification''':

* '''Forward Proxy''': Client knows about proxy, uses it to access external servers (e.g., corporate proxy for internet access)
* '''Reverse Proxy''': Client unaware of proxy, thinks it's talking to the origin server directly

Reverse Proxy Benefits

'''1. Load Balancing'''

Distribute requests across multiple backend servers:

<pre>Client → Reverse Proxy → [Backend 1]
→ [Backend 2]
→ [Backend 3]</pre>
Strategies:

* Round-robin: Cycle through backends in order
* Least connections: Send to backend with fewest active connections
* IP hash: Always send same client to same backend (session affinity)

'''2. TLS Termination'''

The reverse proxy handles TLS encryption/decryption:

<pre>Client ←(HTTPS)→ Reverse Proxy ←(HTTP)→ Backend Servers</pre>
Benefits:

* Backend servers don't need TLS configuration or certificates
* Centralized certificate management
* Reduces computational load on backends (TLS crypto is expensive)
* Simplifies backend server configuration

'''3. Caching'''

Cache responses to reduce backend load:

<pre>Client → Reverse Proxy (check cache) → Backend (if cache miss)</pre>
Subsequent requests for the same resource are served from cache without hitting backends. Can dramatically improve performance and reduce costs.

'''4. Compression'''

The proxy can compress responses (gzip, brotli) before sending to clients, reducing bandwidth:

<pre>Backend → Proxy (compress) → Client</pre>
'''5. Security'''

* Hide backend server details (IP addresses, software versions)
* Web Application Firewall (WAF) functionality
* Rate limiting and DDoS protection
* Centralized logging and monitoring

'''6. Path-Based Routing''' (Critical for Microservices)

Route requests to different backends based on URL path:

<pre>client request /api/users → Reverse Proxy → User Service
client request /api/orders → Reverse Proxy → Order Service
client request /api/products → Reverse Proxy → Product Service</pre>
From the client's perspective, everything is at one domain (e.g., <code>api.example.com</code>). The reverse proxy routes to appropriate microservices based on path. This is the architectural pattern that enables modern microservices.


==== Path-Based Routing in Depth ====

Path-based routing is the killer feature that made HTTP the universal protocol. Let us examine why:

'''The Problem Without Path-Based Routing''':

Suppose you have three backend services:

* User service (manages user accounts)
* Order service (manages orders)
* Product service (manages product catalog)

Without path-based routing, clients must know the specific addresses of each service:

<pre>user-service.example.com/users
order-service.example.com/orders
product-service.example.com/products</pre>
'''Problems''':

# Clients must maintain knowledge of all services
# Adding/removing/renaming services breaks clients
# Difficult to manage CORS (Cross-Origin Resource Sharing) with multiple domains
# More complex DNS management
# More complex TLS certificate management (separate cert for each service)

'''The Solution With Path-Based Routing''':

One unified API endpoint:

<pre>api.example.com/users → routes to User Service
api.example.com/orders → routes to Order Service
api.example.com/products → routes to Product Service</pre>
Reverse proxy configuration:

<pre>if path starts with /users → forward to user-service:3001
if path starts with /orders → forward to order-service:3002
if path starts with /products → forward to product-service:3003</pre>
'''Benefits''':

# Clients see one consistent API domain
# Backend services can change without client awareness
# One TLS certificate for all services
# Simplified CORS configuration
# Centralized authentication and rate limiting

'''This is How Modern Systems Work''':

* '''Kubernetes''': Ingress controllers route paths to services
* '''AWS''': Application Load Balancers route paths to target groups
* '''Microservices''': API Gateway routes paths to microservices
* '''Netflix, Uber, Airbnb''': All use path-based routing at scale

You will implement this pattern in the exercises.

Evolution from Monoliths to Microservices

Understanding path-based routing requires understanding the architectural evolution:

'''Monolithic Architecture''' (Traditional):

<pre>Single Application
├── User Management
├── Order Processing
├── Product Catalog
├── Payment Processing
└── Notification System</pre>
All functionality in one codebase, runs as one process. Advantages: simple deployment, shared database, no network calls between components. Disadvantages: hard to scale specific components, one bug can crash entire system, difficult to update independently.

'''Microservices Architecture''' (Modern):

<pre>User Service ──┐
Order Service ──┤
Product Service ──├── Reverse Proxy ── Clients
Payment Service ──┤
Notification Svc ──┘</pre>
Each service is independent: separate codebase, separate process, separate deployment, separate scaling. Advantages: scale components independently, update services without affecting others, use different technologies per service, isolated failures. Disadvantages: increased operational complexity, network latency between services, distributed system challenges.

'''The Reverse Proxy's Role''': Makes microservices look like a monolith to clients. Clients don't know or care that backend is distributed—they just make requests to one API endpoint.

Observability and Debugging

Modern reverse proxies provide rich observability:

'''Access Logs''': Record every request:

<pre>203.0.113.42 - - [05/Dec/2024:14:23:45 +0000] "GET /api/users HTTP/1.1" 200 1234 "-" "curl/7.68.0"</pre>
Fields: client IP, timestamp, method, path, protocol version, status code, response size, referer, user-agent

'''Error Logs''': Record issues:

<pre>[error] 2024/12/05 14:23:50 upstream timed out (110: Connection timed out) while connecting to upstream</pre>
'''Metrics''': Request rate, error rate, latency percentiles (p50, p95, p99), upstream health

'''Distributed Tracing''': Track requests across services using trace IDs in headers:

<pre>X-Request-ID: 7f2a3b4c-8d9e-4f1a-b2c3-d4e5f6a7b8c9</pre>
When troubleshooting issues, these logs and metrics are invaluable.


== Laboratory Exercises ==


=== Exercise A: DNS Resolution and Analysis ===

Objective: Use DNS client tools to query various record types and observe the DNS resolution process. Understand the difference between authoritative and recursive queries, analyze TTL values, and measure resolution performance.

Required Topology: You must have the Red and Blue namespaces from Lab 8 with IP addresses 10.0.0.1 and 10.0.0.2 respectively, connected via bridge br0. Verify connectivity before proceeding:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.2</syntaxhighlight>
If this fails, recreate your Lab 8 topology before continuing.


==== Basic DNS Queries with dig ====

The <code>dig</code> (Domain Information Groper) tool is the primary DNS debugging utility. It provides detailed information about DNS queries and responses.

'''Step 1''': Verify dig is installed:

<syntaxhighlight lang="bash">dig -v</syntaxhighlight>
'''Expected output''':

<pre>DiG 9.18.1-1ubuntu1.3-Ubuntu</pre>
If not installed: <code>sudo apt install dnsutils</code>

'''Step 2''': Perform a basic A record query for google.com:

<syntaxhighlight lang="bash">dig google.com</syntaxhighlight>
'''Expected output''' (abbreviated):

<pre>; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 163 IN A 142.250.185.46

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Dec 05 14:30:22 UTC 2024
;; MSG SIZE rcvd: 55</pre>
'''Analysis''':

Let us dissect this output:

'''Header Section''':

* <code>status: NOERROR</code> — Query succeeded
* <code>id: 12345</code> — Random query ID for matching requests/responses
* <code>flags: qr rd ra</code> —
** <code>qr</code>: Query Response (this is a response, not a query)
** <code>rd</code>: Recursion Desired (client requested recursive resolution)
** <code>ra</code>: Recursion Available (server supports recursive queries)

'''Question Section''':

<pre>;google.com. IN A</pre>
This shows what we asked for:

* <code>google.com.</code> — Domain name (with trailing dot, the FQDN)
* <code>IN</code> — Internet class (as opposed to other historical DNS classes)
* <code>A</code> — Record type (IPv4 address)

'''Answer Section''':

<pre>google.com. 163 IN A 142.250.185.46</pre>
This is the answer:

* <code>google.com.</code> — Domain queried
* <code>163</code> — TTL (Time To Live) in seconds, countdown starts when received
* <code>IN</code> — Internet class
* <code>A</code> — Record type
* <code>142.250.185.46</code> — The IPv4 address

'''Metadata''':

* <code>Query time: 23 msec</code> — Time to get response (includes network latency and resolution time)
* <code>SERVER: 127.0.0.53#53</code> — DNS server queried (systemd-resolved on Ubuntu)
* <code>MSG SIZE rcvd: 55</code> — Response packet size in bytes

'''Step 3''': Query a specific DNS server directly (bypass systemd-resolved):

<syntaxhighlight lang="bash">dig @8.8.8.8 google.com</syntaxhighlight>
The <code>@8.8.8.8</code> specifies Google Public DNS. Compare the query time to the previous result.

'''Step 4''': Query an IPv6 address (AAAA record):

<syntaxhighlight lang="bash">dig google.com AAAA</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 299 IN AAAA 2607:f8b0:4004:c07::66</pre>
Note: You might see multiple AAAA records if Google has multiple IPv6 addresses for redundancy.

'''Step 5''': Query mail server records (MX records):

<syntaxhighlight lang="bash">dig google.com MX</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 3599 IN MX 10 smtp.google.com.</pre>
The number (10) is the priority. Lower numbers have higher priority. If multiple MX records exist, mail servers try the lowest priority number first.

'''Step 6''': Query name server records (NS records):

<syntaxhighlight lang="bash">dig google.com NS</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 21599 IN NS ns1.google.com.
google.com. 21599 IN NS ns2.google.com.
google.com. 21599 IN NS ns3.google.com.
google.com. 21599 IN NS ns4.google.com.</pre>
These are Google's authoritative name servers. These servers have definitive authority over google.com records.

'''Step 7''': Query text records (TXT records):

<syntaxhighlight lang="bash">dig google.com TXT</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 3599 IN TXT "v=spf1 include:_spf.google.com ~all"
google.com. 3599 IN TXT "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com. 3599 IN TXT "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"</pre>
TXT records store arbitrary text. Common uses: SPF records for email authentication, domain verification for services, DKIM public keys.

'''Step 8''': Request short output format:

<syntaxhighlight lang="bash">dig +short google.com</syntaxhighlight>
'''Expected output''':

<pre>142.250.185.46</pre>
Just the IP address, no verbose information. Useful for scripts.

'''Step 9''': Trace the DNS resolution path:

<syntaxhighlight lang="bash">dig +trace google.com</syntaxhighlight>
'''Expected output''' (abbreviated):

<pre>. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
[... other root servers ...]

;; Received 239 bytes from 8.8.8.8#53 in 23 ms

com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
[... other .com TLD servers ...]

;; Received 1173 bytes from 192.5.5.241#53(a.root-servers.net) in 87 ms

google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
[... other google.com name servers ...]

;; Received 836 bytes from 192.12.94.30#53(e.gtld-servers.net) in 103 ms

google.com. 300 IN A 142.250.185.46

;; Received 55 bytes from 216.239.32.10#53(ns1.google.com) in 11 ms</pre>
This shows the complete resolution process:

# Query root servers → get .com TLD servers
# Query .com TLD servers → get google.com authoritative servers
# Query google.com authoritative servers → get final answer


=== Deliverable A ===

Submit screenshots showing:

# Output of <code>dig</code> commands for A, AAAA, MX, NS, and TXT records for two different domains (suggestion: use a domain like station01.internal.arh.pub.ro, or stud.etti.pub.ro for MX)
# Output of <code>dig +trace</code> for any domain
# Output of two consecutive <code>dig</code> queries showing TTL countdown


=== Exercise B: SSH Configuration and Key-Based Authentication ===

Objective: Configure SSH server and client, generate Ed25519 key pairs, implement key-based authentication, understand the Trust On First Use (TOFU) security model, and observe host key verification


==== Part 1: Verifying SSH Installation ====

'''Step 1''': Check if SSH server is installed:

<syntaxhighlight lang="bash">dpkg -l | grep openssh-server</syntaxhighlight>
'''Expected output''':

<pre>ii openssh-server 1:8.9p1-3ubuntu0.4 amd64 secure shell (SSH) server</pre>
If not installed:

<syntaxhighlight lang="bash">sudo apt install openssh-server openssh-client</syntaxhighlight>
'''Step 2''': Check SSH service status:

<syntaxhighlight lang="bash">sudo systemctl status ssh</syntaxhighlight>
If not running:

<syntaxhighlight lang="bash">sudo systemctl start ssh
sudo systemctl enable ssh</syntaxhighlight>


==== Part 2: Generating SSH Key Pairs ====

We'll generate Ed25519 keys because they offer strong security with small key sizes and fast performance.

'''Step 1''': Generate a key pair as your current user:

<syntaxhighlight lang="bash">ssh-keygen -t ed25519 -C "lab-key"</syntaxhighlight>
'''Expected interaction''':

<pre>Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519): [press Enter]
Enter passphrase (empty for no passphrase): [press Enter for no passphrase]
Enter same passphrase again: [press Enter]
Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xyz789abc123def456ghi789jkl012mno345pqr678 lab-key</pre>
'''Key Decisions''':

* '''File location''': Accept default (<code>~/.ssh/id_ed25519</code>)
* '''Passphrase''': For this lab, skip the passphrase for simplicity. In production, always use a strong passphrase to protect the private key. A passphrase encrypts the private key file—even if an attacker steals the file, they cannot use it without the passphrase.

'''Step 2''': Examine the generated keys:

<syntaxhighlight lang="bash">ls -la ~/.ssh/</syntaxhighlight>
'''Expected output''':

<pre>total 16
drwx------ 2 youruser youruser 4096 Dec 5 14:30 .
drwxr-x--- 8 youruser youruser 4096 Dec 5 14:30 ..
-rw------- 1 youruser youruser 411 Dec 5 14:30 id_ed25519
-rw-r--r-- 1 youruser youruser 99 Dec 5 14:30 id_ed25519.pub</pre>
'''Critical''': Private key (<code>id_ed25519</code>) has mode 600 (readable/writable only by owner). Public key (<code>.pub</code>) has mode 644 (world-readable).

'''Step 3''': View your public key:

<syntaxhighlight lang="bash">cat ~/.ssh/id_ed25519.pub</syntaxhighlight>
This public key can be freely shared. You'll copy this to accounts you want to access.


==== Part 3: Setting Up Key-Based Authentication ====

Configure SSH so you can connect to the <code>sshtest</code> account using your key.

'''Step 1''': Copy your public key to the test user's authorized_keys:

<syntaxhighlight lang="bash">cat ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keys
sudo chmod 600 /home/.ssh/authorized_keys</syntaxhighlight>
'''Step 2''': Verify the setup:

<syntaxhighlight lang="bash">sudo ls -la /home/sshtest/.ssh/
sudo cat ~/.ssh/authorized_keys</syntaxhighlight>
'''Critical Permissions''':

* <code>~/.ssh/</code>: 700 (drwx------)
* <code>authorized_keys</code>: 600 (-rw-------)
* Owner must be the target user

If permissions are wrong, SSH will silently ignore the keys and fall back to password authentication.


==== Part 4: First Connection - Trust On First Use (TOFU) ====

'''Step 1''': Connect to localhost as the test user:

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
'''Expected output (first connection)''':

<pre>The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:abcd1234efgh5678ijkl9012mnop3456qrst7890uvwx.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?</pre>
'''This is the TOFU (Trust On First Use) moment.'''

SSH is asking you to verify the server's identity. In production, you would:

# Check the server's host key fingerprint: <code>ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub</code>
# Compare the fingerprint displayed by SSH with the server's actual fingerprint
# If they match, type <code>yes</code>. If they don't match, '''do not proceed''' (possible MITM attack)

For this lab, type <code>yes</code>:

<pre>Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
sshtest@hostname:~$</pre>
'''You are now connected!''' The connection succeeded using key-based authentication (no password prompt).

'''Step 2''': Explore the connection:

<syntaxhighlight lang="bash">whoami
pwd
hostname</syntaxhighlight>
'''Step 3''': Exit the SSH session:

<syntaxhighlight lang="bash">exit</syntaxhighlight>

==== Part 5: Understanding known_hosts ====

'''Step 1''': Examine the known_hosts file:

<syntaxhighlight lang="bash">cat ~/.ssh/known_hosts</syntaxhighlight>
'''Expected output''':

<pre>localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123def456ghi789jkl012mno345pqr678stu901vwx</pre>
This file stores trusted host keys. Format: <code>hostname/ip algorithm public_key</code>

On subsequent connections, SSH verifies the server presents the same host key. If the key changes, SSH displays a warning.

'''Step 2''': Connect again:

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
'''Expected behavior''': No host key prompt this time—immediate connection. SSH verified the host key matches the one in known_hosts.

'''Step 3''': Exit:

<syntaxhighlight lang="bash">exit</syntaxhighlight>

==== Part 6: Simulating a Host Key Change ====

We'll deliberately change the server's host key to see SSH's security warning.

'''Step 1''': Regenerate the host key:

<syntaxhighlight lang="bash">sudo rm /etc/ssh/ssh_host_ed25519_key*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo systemctl restart sshd</syntaxhighlight>
'''Step 2''': Attempt to connect:

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
'''Expected output''':

<pre>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:new_fingerprint_here.
Please contact your system administrator.
Add correct host key in /home/youruser/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/youruser/.ssh/known_hosts:1
remove with:
ssh-keygen -f "/home/youruser/.ssh/known_hosts" -R "localhost"
Host key for localhost has changed and you have requested strict checking.
Host key verification failed.</pre>
'''SSH refuses to connect!''' This is the security mechanism in action. SSH detected that the server's host key changed, which could indicate:

# Legitimate server reinstallation
# Man-in-the-middle attack

SSH conservatively assumes the worst case and blocks the connection.

'''Step 3''': Remove the old host key:

<syntaxhighlight lang="bash">ssh-keygen -f ~/.ssh/known_hosts -R "localhost"</syntaxhighlight>
'''Expected output''':

<pre># Host localhost found: line 1
/home/youruser/.ssh/known_hosts updated.
Original contents retained as /home/youruser/.ssh/known_hosts.old</pre>
'''Step 4''': Reconnect (you'll see the TOFU prompt again):

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
Type <code>yes</code> to trust the new host key.


=== Deliverable B ===

Submit screenshots showing:

# The TOFU prompt on first SSH connection
# Contents of <code>~/.ssh/id_ed25519.pub</code>
# Contents of <code>~/.ssh/authorized_keys</code>
# Contents of <code>~/.ssh/known_hosts</code>
# The "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message
# Successful SSH connection after resolving the host key change


=== Exercise C: HTTP Services and Reverse Proxy ===

'''Objective''': Build simple HTTP backend services in network namespaces and configure Caddy as a reverse proxy with path-based routing.


==== Part 1: Installing Caddy ====

'''Step 1''': Install Caddy:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y caddy curl</syntaxhighlight>
'''Step 2''': Verify installation:

<syntaxhighlight lang="bash">caddy version</syntaxhighlight>
Expected output: <code>v2.6.2</code> or similar


==== Part 2: Creating Simple Backend Services ====

We'll create basic file-serving HTTP servers in the Red and Blue namespaces.

'''Step 1''': Create content directories and files for Red service:

<syntaxhighlight lang="bash"># Create directory for Red service
mkdir -p ~/red-service
cd ~/red-service

# Create an index file
cat > index.html << 'EOF'
<!DOCTYPE html>
<html>
<head><title>Red Service</title></head>
<body>
<h1>Red Service</h1>
Hello from Red namespace!
IP: 10.0.0.1 | Port: 8001
</body>
</html>
EOF

# Create an API response file
mkdir -p api
cat > api/data.json << 'EOF'
{
"service": "Red Service",
"namespace": "red",
"ip": "10.0.0.1",
"status": "running"
}
EOF</syntaxhighlight>
'''Step 2''': Start Red service in its namespace:

<syntaxhighlight lang="bash"># Start HTTP server in Red namespace (run in background with &)
sudo ip netns exec red python3 -m http.server 8001 --bind 10.0.0.1 --directory ~/red-service &</syntaxhighlight>
Expected output: <code>Serving HTTP on 10.0.0.1 port 8001 (http://10.0.0.1:8001/) ...</code>

'''Step 3''': Create content for Blue service:

<syntaxhighlight lang="bash"># Create directory for Blue service
mkdir -p ~/blue-service
cd ~/blue-service

# Create an index file
cat > index.html << 'EOF'
<!DOCTYPE html>
<html>
<head><title>Blue Service</title></head>
<body>
<h1>Blue Service</h1>
Hello from Blue namespace!
IP: 10.0.0.2 | Port: 8002
</body>
</html>
EOF

# Create an API response file
mkdir -p api
cat > api/data.json << 'EOF'
{
"service": "Blue Service",
"namespace": "blue",
"ip": "10.0.0.2",
"status": "running"
}
EOF</syntaxhighlight>
'''Step 4''': Start Blue service in its namespace:

<syntaxhighlight lang="bash"># Start HTTP server in Blue namespace
sudo ip netns exec blue python3 -m http.server 8002 --bind 10.0.0.2 --directory ~/blue-service &</syntaxhighlight>
'''Step 5''': Test the backend services directly:

<syntaxhighlight lang="bash"># Test Red service
curl http://10.0.0.1:8001/

# Test Blue service
curl http://10.0.0.2:8002/

# Test JSON endpoints
curl http://10.0.0.1:8001/api/data.json
curl http://10.0.0.2:8002/api/data.json</syntaxhighlight>
You should see the HTML and JSON content from each service.


==== Part 3: Configuring Caddy Reverse Proxy ====

'''Step 1''': Create a Caddyfile:

<syntaxhighlight lang="bash">cd ~
cat > Caddyfile << 'EOF'
# Caddy Reverse Proxy Configuration

:8080 {
# Health check endpoint
handle /health {
respond "OK - API Gateway Running" 200
}

# Root path
handle / {
respond "API Gateway - Use /red/ or /blue/ paths" 200
}

# Route /red/* to Red service (strips /red prefix)
handle_path /red/* {
reverse_proxy 10.0.0.1:8001
}

# Route /blue/* to Blue service (strips /blue prefix)
handle_path /blue/* {
reverse_proxy 10.0.0.2:8002
}

# Enable logging
log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Understanding the Configuration''':

* <code>:8080</code> - Listen on port 8080
* <code>handle /health</code> - Health check endpoint (doesn't go to backends)
* <code>handle_path /red/*</code> - Strips <code>/red</code> prefix before forwarding
** Client requests <code>/red/api/data.json</code> → Backend receives <code>/api/data.json</code>
* <code>reverse_proxy 10.0.0.1:8001</code> - Forward to Red service
* Similar logic for Blue service

'''Step 2''': Start Caddy:

<syntaxhighlight lang="bash">caddy run --config ~/Caddyfile</syntaxhighlight>
Expected output:

<pre>INFO using config from file
INFO serving initial configuration</pre>
Leave this terminal open to see request logs.


==== Part 4: Testing Path-Based Routing ====

Open a '''new terminal''' for testing.

'''Step 1''': Test the root path:

<syntaxhighlight lang="bash">curl http://localhost:8080/</syntaxhighlight>
Expected output: <code>API Gateway - Use /red/ or /blue/ paths</code>

'''Step 2''': Test health check:

<syntaxhighlight lang="bash">curl http://localhost:8080/health</syntaxhighlight>
Expected output: <code>OK - API Gateway Running</code>

'''Step 3''': Test Red service through proxy:

<syntaxhighlight lang="bash">curl http://localhost:8080/red/</syntaxhighlight>
You should see the Red service HTML page.

<syntaxhighlight lang="bash">curl http://localhost:8080/red/api/data.json</syntaxhighlight>
Expected output:

<syntaxhighlight lang="json">{
"service": "Red Service",
"namespace": "red",
"ip": "10.0.0.1",
"status": "running"
}</syntaxhighlight>
'''Step 4''': Test Blue service through proxy:

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/</syntaxhighlight>
You should see the Blue service HTML page.

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/api/data.json</syntaxhighlight>
Expected output:

<syntaxhighlight lang="json">{
"service": "Blue Service",
"namespace": "blue",
"ip": "10.0.0.2",
"status": "running"
}</syntaxhighlight>
'''Step 5''': Test with verbose output to see headers:

<syntaxhighlight lang="bash">curl -v http://localhost:8080/red/api/data.json</syntaxhighlight>
Expected output (key parts):

<pre>> GET /red/api/data.json HTTP/1.1
> Host: localhost:8080
...
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Caddy
...
{JSON response}</pre>
'''Observation''':

* Client requested <code>/red/api/data.json</code>
* Caddy stripped <code>/red</code> and forwarded <code>/api/data.json</code> to backend
* Response comes back through Caddy (notice <code>Server: Caddy</code> header)


==== Part 5: Understanding the Flow ====

'''Request Flow Diagram''':

<pre>Client Request: http://localhost:8080/red/api/data.json
|
v
Caddy (port 8080)
|
| Strips /red prefix
| Path becomes: /api/data.json
v
Red Service (10.0.0.1:8001)
|
| Serves file: ~/red-service/api/data.json
v
Response back through Caddy
|
v
Client receives JSON</pre>

==== Part 6: Cleanup ====

When finished testing:

<syntaxhighlight lang="bash"># Stop Caddy (Ctrl+C in Caddy terminal)

# Kill Python servers
pkill -f "python3 -m http.server 8001"
pkill -f "python3 -m http.server 8002"

# Or kill all Python HTTP servers
sudo pkill -f "http.server"</syntaxhighlight>

=== Deliverable C ===

Submit screenshots showing:

# Output of <code>curl http://localhost:8080/</code> (root path)
# Output of <code>curl http://localhost:8080/health</code>
# Output of <code>curl http://localhost:8080/red/api/data.json</code>
# Output of <code>curl http://localhost:8080/blue/api/data.json</code>
# Output of <code>curl -v http://localhost:8080/red/</code> showing response headers
# Your complete Caddyfile contents


== Common Troubleshooting ==

This section covers common issues you may encounter during the lab exercises.


=== DNS Issues ===

'''Problem''': DNS queries fail or time out

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check DNS resolver configuration
cat /etc/resolv.conf

# Test with different DNS servers
dig @8.8.8.8 google.com
dig @1.1.1.1 google.com</syntaxhighlight>
'''Solutions''':

* Verify network connectivity: <code>ping 8.8.8.8</code>
* Check firewall rules: <code>sudo iptables -L -n | grep 53</code>
* Try alternative DNS servers

'''Problem''': "connection timed out; no servers could be reached"

'''Cause''': No DNS resolver configured or resolver unreachable

'''Solution''':

<syntaxhighlight lang="bash"># Add Google DNS to resolv.conf
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf</syntaxhighlight>

=== SSH Issues ===

'''Problem''': "Permission denied (publickey)"

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check SSH with verbose output
ssh -v testuser@10.0.0.2

# Verify key permissions
ls -la ~/.ssh/id_ed25519

# Check authorized_keys on server
sudo ls -la /home/testuser/.ssh/authorized_keys</syntaxhighlight>
'''Common Causes''':

# Wrong permissions on private key (must be 600)
# Wrong permissions on authorized_keys (must be 600)
# Wrong ownership of .ssh directory
# Public key not in authorized_keys
# Private key not loaded

'''Solutions''':

<syntaxhighlight lang="bash"># Fix permissions
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

# Verify key is loaded
ssh-add -l

# Add key if not loaded
ssh-add ~/.ssh/id_ed25519</syntaxhighlight>
'''Problem''': "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!"

'''Cause''': Server's host key changed (legitimate reinstall or potential MITM attack)

'''Solution''' (if change is legitimate):

<syntaxhighlight lang="bash"># Remove old host key
ssh-keygen -R 10.0.0.2

# Reconnect and verify new fingerprint
ssh testuser@10.0.0.2</syntaxhighlight>
'''Problem''': SSH connection hangs

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check if SSH server is running
sudo ss -tlnp | grep :22

# Test connectivity
nc -zv 10.0.0.2 22</syntaxhighlight>
'''Solutions''':

* Restart SSH server: <code>sudo systemctl restart sshd</code>
* Check firewall rules
* Verify network namespace connectivity


=== HTTP/Caddy Issues ===

'''Problem''': Caddy fails to start

'''Diagnostics''':

<syntaxhighlight lang="bash"># Validate configuration
caddy validate --config /etc/caddy/Caddyfile

# Check if port is already in use
sudo ss -tlnp | grep :8080

# View Caddy logs
sudo journalctl -u caddy -n 50</syntaxhighlight>
'''Common Causes''':

# Port already in use
# Syntax error in Caddyfile
# Permission issues

'''Solutions''':

<syntaxhighlight lang="bash"># Kill process using port 8080
sudo fuser -k 8080/tcp

# Fix Caddyfile syntax
caddy fmt --overwrite /etc/caddy/Caddyfile

# Run Caddy with elevated privileges if needed
sudo caddy run --config /etc/caddy/Caddyfile</syntaxhighlight>
'''Problem''': Reverse proxy returns "502 Bad Gateway"

'''Cause''': Backend service not running or unreachable

'''Diagnostics''':

<syntaxhighlight lang="bash"># Test backend directly
curl http://10.0.0.1:8001
curl http://10.0.0.2:8002

# Check if backend processes are running
sudo ip netns exec red ps aux | grep python
sudo ip netns exec blue ps aux | grep python

# Check connectivity from host to namespace
ping -c 2 10.0.0.1
ping -c 2 10.0.0.2</syntaxhighlight>
'''Solutions''':

* Restart backend services
* Verify namespace network configuration
* Check backend logs for errors

'''Problem''': Path routing not working correctly

'''Diagnostics''':

<syntaxhighlight lang="bash"># Test with verbose curl
curl -v http://localhost:8080/red/

# Check Caddy access logs
sudo tail -f /var/log/caddy/access.log</syntaxhighlight>
'''Solution''': Verify Caddyfile syntax, especially <code>handle_path</code> directives. Ensure path prefixes match exactly.


=== Network Namespace Issues ===

'''Problem''': Cannot ping between namespaces

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check interface status
sudo ip netns exec red ip link show
sudo ip netns exec blue ip link show

# Check IP addresses
sudo ip netns exec red ip addr show
sudo ip netns exec blue ip addr show

# Check routing
sudo ip netns exec red ip route show</syntaxhighlight>
'''Solutions''':

* Recreate namespace configuration from Lab 8
* Verify veth pairs are connected
* Check bridge configuration

'''Problem''': Services in namespace cannot access internet

'''Cause''': No default gateway or NAT configured

'''Solution''': Configure NAT on host (if needed for external access):

<syntaxhighlight lang="bash"># Enable IP forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# Add NAT rule
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE</syntaxhighlight>

== Additional Protocol Information ==

This appendix provides information about other application protocols you may encounter.


=== Email Protocols ===

'''SMTP (Simple Mail Transfer Protocol)'''

* Port: 25 (unencrypted), 587 (submission with STARTTLS), 465 (SMTPS)
* Purpose: Sending email between servers
* Client-to-server: Port 587
* Server-to-server: Port 25
* Note: Port 25 often blocked by ISPs to prevent spam

'''IMAP (Internet Message Access Protocol)'''

* Port: 143 (unencrypted), 993 (IMAPS)
* Purpose: Reading email with server synchronization
* Advantages: Emails stay on server, accessible from multiple devices
* Modern replacement for POP3

'''POP3 (Post Office Protocol v3)'''

* Port: 110 (unencrypted), 995 (POP3S)
* Purpose: Downloading email to client
* Downloads emails and typically deletes from server
* Legacy protocol, IMAP preferred today


=== Database Protocols ===

'''MySQL'''

* Port: 3306
* Protocol: MySQL wire protocol (proprietary)
* Common tools: mysql client, MySQL Workbench

'''PostgreSQL'''

* Port: 5432
* Protocol: PostgreSQL wire protocol
* Common tools: psql client, pgAdmin

'''MongoDB'''

* Port: 27017
* Protocol: MongoDB wire protocol
* NoSQL document database

'''Redis'''

* Port: 6379
* Protocol: RESP (Redis Serialization Protocol)
* In-memory data structure store


=== Other Common Protocols ===

'''FTP (File Transfer Protocol)'''

* Port: 21 (control), 20 (data)
* Legacy file transfer protocol
* Security issues: Transmits credentials in cleartext
* Modern alternatives: SFTP (SSH File Transfer Protocol), FTPS (FTP over SSL/TLS)

'''LDAP (Lightweight Directory Access Protocol)'''

* Port: 389 (unencrypted), 636 (LDAPS)
* Purpose: Directory services (user authentication, organizational data)
* Common in enterprises for centralized authentication

'''RDP (Remote Desktop Protocol)'''

* Port: 3389
* Purpose: Remote desktop access (Windows)
* Proprietary Microsoft protocol

'''VNC (Virtual Network Computing)'''

* Port: 5900+ (5900, 5901, etc.)
* Purpose: Remote desktop access (cross-platform)
* Open protocol, multiple implementations

'''NTP (Network Time Protocol)'''

* Port: 123
* Purpose: Clock synchronization
* Critical for distributed systems, logging, security

'''Syslog'''

* Port: 514 (UDP/TCP)
* Purpose: Logging infrastructure
* Centralized log collection


=== Ports to Avoid ===

'''Insecure Legacy Protocols''' (never use in production):

* Port 21: FTP (use SFTP or FTPS instead)
* Port 23: Telnet (use SSH instead)
* Port 69: TFTP (use SFTP or SCP instead)
* Port 110: POP3 unencrypted (use POP3S or IMAP)
* Port 143: IMAP unencrypted (use IMAPS)
* Port 389: LDAP unencrypted (use LDAPS)
* Port 445: SMB (often exploited, use VPN if needed)
* Port 512-514: rlogin, rsh, rexec (use SSH instead)

These protocols transmit data (including credentials) in cleartext and/or have known security vulnerabilities.


== Deliverables and Assessment ==

Submit a single PDF document containing all required elements. Organize clearly with section headers matching exercise labels.


== Additional Resources ==

This lab introduced the dominant application layer protocols that form the foundation of modern internet services. You now understand how DNS enables service discovery, SSH provides secure remote access, and HTTP(S) serves as the universal protocol for APIs and web services.


=== For Further Study ===

'''DNS Deep Dives''':

* Setting up authoritative DNS with BIND9 or PowerDNS
* DNS security: DNSSEC for cryptographic verification of DNS responses
* DNS over HTTPS (DoH) and DNS over TLS (DoT) for encrypted DNS queries
* Dynamic DNS (DDNS) and service discovery patterns
* Split-horizon DNS for internal vs. external name resolution
* DNS-based load balancing and geographic routing (GeoDNS)

'''SSH Advanced Topics''':

* SSH tunneling: Local forwarding (<code>-L</code>), remote forwarding (<code>-R</code>), dynamic forwarding (<code>-D</code>)
* ProxyJump (<code>-J</code>) for accessing hosts through bastion servers
* SSH certificates (different from host keys) for scalable authentication
* SSH agent forwarding security considerations
* SSH config files (<code>~/.ssh/config</code>) for managing multiple hosts
* SSH as SOCKS proxy for secure browsing

'''HTTP/HTTPS Evolution''':

* HTTP/2 improvements: multiplexing, server push, header compression, binary protocol
* HTTP/3 and QUIC: UDP-based transport with built-in encryption
* WebSockets for real-time bidirectional communication
* Server-Sent Events (SSE) for server-push updates
* gRPC for efficient RPC over HTTP/2
* GraphQL as alternative to REST for flexible API queries

'''Web Server Configuration''':

* Nginx advanced reverse proxy patterns
* HAProxy for high-performance load balancing
* Load balancing algorithms: round-robin, least connections, IP hash, consistent hashing
* SSL/TLS termination best practices
* Certificate management with Let's Encrypt
* HTTP caching: proxy caching, CDN integration, cache invalidation strategies
* Security headers: HSTS, Content-Security-Policy, X-Frame-Options, CORS

'''Modern Architecture Patterns''':

* Microservices architecture: benefits and challenges
* Service mesh: Istio, Linkerd, Consul Connect
* API gateways: Kong, Ambassador, Traefik, AWS API Gateway
* Kubernetes Ingress controllers and service routing
* Serverless architecture and function-as-a-service (FaaS)
* Event-driven architectures: message queues, pub/sub patterns

'''Other Application Protocols''':

* Email protocols: SMTP for sending, IMAP for retrieval, SPF/DKIM/DMARC for authentication
* Database wire protocols: MySQL, PostgreSQL, MongoDB, Redis
* Message queue protocols: AMQP (RabbitMQ), Kafka protocol
* Monitoring and observability: Prometheus metrics, StatsD, OpenTelemetry, syslog


=== Relevant Manual Pages ===

<syntaxhighlight lang="bash">man dig # DNS query tool
man nslookup # DNS lookup utility
man host # DNS lookup utility
man ssh # SSH client
man sshd # SSH server daemon
man sshd_config # SSH server configuration
man ssh_config # SSH client configuration
man ssh-keygen # SSH key generation and management
man ssh-add # SSH agent key management
man curl # HTTP client
man wget # HTTP client alternative</syntaxhighlight>

=== Online Resources ===

'''DNS''':

* [https://www.rfc-editor.org/rfc/rfc1034 DNS RFC 1034] - Domain Names: Concepts and Facilities
* [https://www.rfc-editor.org/rfc/rfc1035 DNS RFC 1035] - Domain Names: Implementation and Specification
* [http://www.zytrax.com/books/dns/ DNS Zone File Guide] - Comprehensive DNS resource
* [https://developers.google.com/speed/public-dns Google Public DNS] - Documentation and best practices
* [https://www.cloudflare.com/learning/dns/what-is-dns/ Cloudflare 1.1.1.1] - DNS learning center

'''SSH''':

* [https://www.rfc-editor.org/rfc/rfc4251 SSH Protocol RFC 4251] - SSH Architecture
* [https://www.ssh.com/academy/ssh SSH.com Academy] - Comprehensive SSH tutorials
* [https://infosec.mozilla.org/guidelines/openssh Mozilla SSH Guidelines] - Security best practices
* [https://ed25519.cr.yp.to/ Ed25519 Benefits] - Information about Ed25519 cryptography

'''HTTP/HTTPS''':

* [https://www.rfc-editor.org/rfc/rfc7230 HTTP/1.1 RFC 7230-7235] - HTTP specification series
* [https://www.rfc-editor.org/rfc/rfc7540 HTTP/2 RFC 7540] - HTTP/2 specification
* [https://www.rfc-editor.org/rfc/rfc9114 HTTP/3 RFC 9114] - HTTP/3 specification
* [https://developer.mozilla.org/en-US/docs/Web/HTTP MDN HTTP Documentation] - Comprehensive HTTP reference
* [https://hpbn.co/ High Performance Browser Networking] - Free book by Ilya Grigorik

'''Web Servers and Reverse Proxies''':

* [https://caddyserver.com/docs/ Caddy Documentation] - Modern web server with automatic HTTPS
* [https://nginx.org/en/docs/ Nginx Documentation] - High-performance web server and reverse proxy
* [https://www.haproxy.org/documentation.html HAProxy Documentation] - Load balancer and proxy
* [https://doc.traefik.io/traefik/ Traefik Documentation] - Modern HTTP reverse proxy and load balancer

'''Security''':

* [https://owasp.org/www-project-top-ten/ OWASP Top 10] - Web application security risks
* [https://ssl-config.mozilla.org/ Mozilla SSL Configuration Generator] - TLS best practices
* [https://letsencrypt.org/docs/ Let's Encrypt] - Free TLS certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of websites

Practice Environments

* [https://overthewire.org/wargames/bandit/ OverTheWire Bandit] - Linux command-line challenges including networking
* [https://www.hackthebox.com/ HackTheBox] - Penetration testing practice with networking components
* [https://tryhackme.com/ TryHackMe] - Guided cybersecurity learning including networking modules
* [https://www.katacoda.com/courses/kubernetes Kubernetes Playground] - Practice with modern orchestration
* [https://labs.play-with-docker.com/ Docker Playground] - Free Docker environment for testing

OS Lab 10 - Containers and Docker

2025-12-16T16:32:09Z

Vserbu: /* Part 3: Test Persistence */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how containers use Linux kernel namespaces (PID, mount, network, UTS, IPC, user, cgroup) to provide process isolation without requiring separate operating systems or hypervisors.
* Differentiate between container images (immutable filesystem templates) and running containers (ephemeral process instances in isolated namespaces).
* Understand how OverlayFS provides efficient layered filesystems that allow multiple containers to share common base layers while maintaining separate writable layers.
* Apply cgroup resource limits to constrain container CPU, memory, and I/O usage, preventing resource monopolization.
* Configure Docker networking using custom bridges, port mapping (NAT), and container-to-container communication with automatic DNS resolution.
* Use volumes and bind mounts to persist data beyond container lifecycles and share data between containers and the host.
* Build multi-container applications with coordinated networking and resource management, demonstrating modern microservices architecture patterns.
* Connect container concepts to previous labs: relate network namespaces to Lab 7, mount namespaces to Lab 2, PID namespaces to Lab 3, and Docker networking to Labs 7-9.


== Introduction ==


=== From Manual Isolation to Automated Containers ===

In Labs 7-9, you manually constructed network isolation using Linux kernel primitives. You created virtual network interfaces with <code>ip link add type veth</code>, configured bridges with <code>ip link add type bridge</code>, established isolated network stacks with <code>ip netns add</code>, and set up routing and NAT rules. Through this hands-on work, you gained deep insight into how the Linux kernel provides network isolation at the namespace level.

Every time you executed <code>sudo ip netns exec red ping 10.0.0.3</code>, you were demonstrating a fundamental concept: the kernel can create completely isolated environments where processes see only a subset of system resources. The <code>red</code> namespace had its own network interfaces, its own routing table, and its own firewall rules—completely invisible to processes running in other namespaces or on the host.

This isolation is powerful, but network namespaces are just one of seven namespace types that the Linux kernel provides. To fully isolate an application and create what we call a "container," you need:

* '''Network namespace''' (<code>net</code>): Isolated network stack—you've mastered this in Labs 7-9
* '''PID namespace''' (<code>pid</code>): Isolated process tree—each namespace has its own PID 1
* '''Mount namespace''' (<code>mnt</code>): Isolated filesystem view—different root directory from the host
* '''UTS namespace''' (<code>uts</code>): Isolated hostname—each container can have its own hostname
* '''IPC namespace''' (<code>ipc</code>): Isolated inter-process communication—shared memory, semaphores, message queues
* '''User namespace''' (<code>user</code>): Isolated UIDs/GIDs—security boundary for privilege separation
* '''Cgroup namespace''' (<code>cgroup</code>): Isolated view of control group hierarchy

Additionally, you need:

* '''Control groups (cgroups)''' to limit CPU, memory, and I/O resources
* '''Copy-on-write filesystems''' (OverlayFS) for efficient storage
* '''Image management''' for distributing application packages
* '''Orchestration''' for managing the lifecycle of multiple isolated environments

Manually setting up all of these components for every application would require hundreds of commands and deep kernel knowledge. This is the problem that containerization technology solves.


=== What are Containers? ===

A '''container''' is an isolated process (or process tree) that uses Linux kernel features—namespaces, cgroups, and layered filesystems—to provide the illusion of running in a separate system. Containers package an application with its dependencies, libraries, and configuration into a single unit that can run consistently across different environments.

Containers are not a specific product or tool—they are a pattern for using kernel isolation features. Multiple container runtimes exist, each implementing this pattern:

'''Container Runtimes:'''

* '''Docker''': The most widely adopted container platform, providing a complete ecosystem (daemon, CLI, image format, registry)
* '''Podman''': Daemonless container engine, compatible with Docker images and commands, can run rootless
* '''containerd''': Industry-standard container runtime, used by Kubernetes and Docker (as of Docker 1.11+)
* '''CRI-O''': Lightweight container runtime built for Kubernetes, implementing the Container Runtime Interface (CRI)
* '''LXC/LXD''': System containers that more closely resemble traditional VMs, providing full init systems

'''What Container Runtimes Provide:'''

# '''Namespace Management''': Automatically create and configure all necessary namespace types
# '''Filesystem Layers''': Use OverlayFS or similar copy-on-write filesystems for efficient storage
# '''Network Configuration''': Set up bridges, veth pairs, and NAT rules automatically
# '''Resource Control''': Configure cgroups to enforce CPU and memory limits
# '''Image Distribution''': Provide standard formats (OCI) for packaging and distributing applications
# '''Lifecycle Management''': Offer commands to create, start, stop, and remove containers


=== Docker as a Container Runtime ===

In this lab, we use '''Docker''' because it is the most widely deployed and well-documented container runtime. Docker's architecture consists of:

* '''Docker Engine (dockerd)''': Daemon that manages containers
* '''Docker CLI (docker)''': Command-line interface for interacting with the daemon
* '''containerd''': Lower-level runtime that Docker uses internally
* '''runc''': OCI-compliant runtime that actually creates and runs containers

When you execute <code>docker run nginx</code>, Docker performs approximately 50-100 system calls to configure namespaces, mount filesystems, set up networking, and start the process—all operations you could do manually but would require significant time and expertise.

The concepts you learn with Docker apply to all container runtimes, as they all use the same underlying kernel features. The commands may differ (e.g., <code>podman run</code> instead of <code>docker run</code>), but the fundamental mechanisms remain the same.


=== The Shift in Software Deployment ===

Containers represent a fundamental paradigm shift in how we think about software deployment and infrastructure management.

'''Traditional Deployment Model (Pre-Container Era):'''

<pre>1. Provision a server (physical or virtual machine)
2. Install operating system (Ubuntu, RHEL, etc.)
3. Install runtime dependencies (Python 3.9, Node.js 16, specific library versions)
4. Configure environment variables, users, permissions
5. Deploy application code
6. Configure monitoring, logging, security
7. Hope everything works the same as on your development machine
8. Troubleshoot when it doesn't ("works on my machine" problem)</pre>
This model suffers from several critical issues:

* '''Dependency Hell''': Different applications require different, potentially conflicting library versions
* '''Configuration Drift''': Development, staging, and production environments gradually diverge
* '''Snowflake Servers''': Each server becomes unique and unreproducible
* '''Slow Deployment''': Setting up a new environment can take hours or days
* '''Poor Resource Utilization''': Applications can't share servers due to dependency conflicts

'''Container-Based Deployment Model:'''

<pre>1. Developer creates Dockerfile specifying exact environment
2. Build process creates immutable container image with all dependencies
3. Image tested in CI/CD pipeline (identical to production)
4. Image deployed to any server with Docker installed
5. Container starts in seconds with guaranteed-identical environment
6. Multiple isolated applications run on same host without conflicts</pre>
This model provides:

* '''Immutable Infrastructure''': Images never change after building; deploy new versions rather than modifying running systems
* '''Reproducibility''': Development environment = testing environment = production environment
* '''Portability''': "Build once, run anywhere" (laptop, data center, cloud)
* '''Efficiency''': Run 10-100 containers on a single host (vs. 5-10 VMs)
* '''Rapid Deployment''': Start containers in milliseconds vs. minutes for VMs
* '''Microservices Architecture''': Enables decomposing monoliths into independently deployable services

This shift has revolutionized software engineering, enabling modern DevOps practices, continuous deployment, and cloud-native architectures. Companies like Netflix, Uber, and Airbnb run millions of containers to serve billions of requests daily.


=== Containers vs Virtual Machines ===

Understanding the architectural difference between containers and virtual machines is crucial for appreciating why containers have become the dominant deployment model.

'''Virtual Machine Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Libraries │ │ Libraries │ │ Libraries │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Guest OS │ │ Guest OS │ │ Guest OS │
│ (Kernel) │ │ (Kernel) │ │ (Kernel) │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
Hypervisor (VMware, KVM, Xen)
─────────────────────────────────────────────────
Host Operating System & Kernel
─────────────────────────────────────────────────
Hardware</pre>
'''Characteristics:'''

* Each VM runs a complete guest operating system with its own kernel
* Hypervisor emulates hardware, providing virtual CPUs, RAM, disks, NICs
* Strong isolation (separate kernels mean vulnerabilities in one VM don't affect others)
* Heavy resource consumption (each OS kernel needs 1-2GB RAM)
* Slow startup (boot entire OS: 30-60 seconds)
* Large disk footprint (each VM stores complete OS: 1-10GB)

'''Container Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Libraries │ │ Libraries │ │ Libraries │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
Container Runtime (Docker Engine)
─────────────────────────────────────────────────
Host Operating System & Shared Kernel
─────────────────────────────────────────────────
Hardware</pre>
'''Characteristics:'''

* All containers share the host's kernel (no guest OS needed)
* Container runtime manages namespace and cgroup isolation
* Lightweight isolation (namespaces separate processes, but they're still just processes)
* Minimal resource overhead (containers use only incremental memory beyond their application)
* Fast startup (start process in isolated namespace: milliseconds)
* Small disk footprint (layered filesystem shares common base images: 10-100MB incremental)

'''The Trade-off:'''

Virtual machines provide '''stronger security isolation''' at the cost of '''resource efficiency'''. If your threat model requires complete kernel isolation (e.g., multi-tenant cloud providers hosting untrusted code), VMs are appropriate.

Containers provide '''lighter-weight isolation''' with '''much better resource efficiency'''. If you're running your own applications on your own infrastructure, containers are usually the right choice. You can run 10-100 containers on hardware that would support only 5-10 VMs.

'''An Important Insight:''' When you run <code>ps aux</code> on the host, you see container processes. They're not hidden inside separate kernels like VM processes would be. This demonstrates that containers are just isolated processes on the host—the kernel makes them appear isolated through namespaces, but they're fundamentally just processes.

This is both a feature (efficiency, observability) and a constraint (shared kernel means a kernel vulnerability could affect all containers). Modern container security practices use defense-in-depth: namespaces + cgroups + seccomp + AppArmor/SELinux + user namespaces to create multiple security layers.


== Prerequisites ==


=== System Requirements ===

* '''Operating System''': Linux-based system (Ubuntu 20.04+ recommended, but Debian, Fedora, CentOS also supported)
* '''RAM''': Minimum 2GB, 4GB recommended for comfortable operation
* '''Disk Space''': At least 20GB free (Docker images and container layers consume significant space)
* '''CPU''': Any modern x86_64 or ARM64 processor
* '''Privileges''': Root access via <code>sudo</code> (required for Docker installation and initial setup)
* '''Kernel''': Minimum Linux kernel 3.10 (kernel 4.0+ recommended for full feature support)

'''Check your kernel version:'''

<syntaxhighlight lang="bash">uname -r</syntaxhighlight>
If below 3.10, you'll need to update your kernel before proceeding.

'''Check available disk space:'''

<syntaxhighlight lang="bash">df -h /var/lib/docker</syntaxhighlight>
Docker stores images and containers in <code>/var/lib/docker</code> by default. Ensure you have sufficient space.


=== Required Packages ===

Before beginning, ensure the following packages are installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg \
lsb-release \
bridge-utils \
net-tools</syntaxhighlight>
'''Package descriptions:'''

* <code>apt-transport-https</code>: Enables apt to retrieve packages over HTTPS
* <code>ca-certificates</code>: Common CA certificates for SSL verification
* <code>curl</code>: Command-line tool for transferring data (used to download Docker's GPG key)
* <code>gnupg</code>: GNU Privacy Guard for verifying package signatures
* <code>lsb-release</code>: Provides Linux Standard Base version information (used to detect Ubuntu version)
* <code>bridge-utils</code>: Tools for managing bridge devices (<code>brctl</code> command)
* <code>net-tools</code>: Legacy networking tools (<code>ifconfig</code>, <code>netstat</code>) for compatibility


=== Knowledge Prerequisites ===

This lab builds directly on concepts from previous labs. You should be comfortable with:

'''From Lab 2 (Filesystems):'''

* Filesystem hierarchy and directory structure
* Mount points and the <code>mount</code> command
* Understanding of <code>/</code>, <code>/etc</code>, <code>/var</code>, <code>/usr</code> purposes
* File permissions and ownership (<code>chmod</code>, <code>chown</code>)
* Symbolic links and filesystem navigation

'''From Lab 3 (Processes and Jobs):'''

* Process IDs (PIDs) and process hierarchy
* Parent-child process relationships
* <code>ps aux</code> command and process listing
* Foreground vs. background processes
* Process signals (SIGTERM, SIGKILL)

'''From Lab 4 (Users, Groups, and Permissions):'''

* User IDs (UIDs) and group IDs (GIDs)
* Root vs. unprivileged users
* <code>sudo</code> for privilege escalation
* File and directory permissions (read, write, execute)
* Security implications of running processes as root

'''From Lab 7 (Network Fundamentals):'''

* Network interfaces and IP addresses
* Bridges and virtual ethernet (veth) pairs
* Subnets and CIDR notation
* Routing tables and default gateways
* Network Address Translation (NAT)
* '''Network namespaces''' (<code>ip netns add</code>, <code>ip netns exec</code>)

This is crucial—Docker networking uses the exact same mechanisms you built manually.

'''From Lab 8 (Transport and Security):'''

* TCP and UDP protocols
* Port numbers and socket addresses (IP:PORT)
* Client-server communication model
* The concept of listening vs. connecting
* TLS/SSL (Docker can use HTTPS for secure image distribution)

'''From Lab 9 (Application Protocols):'''

* HTTP/HTTPS protocols
* Reverse proxies and path-based routing
* DNS and hostname resolution
* Caddy web server configuration
* Multi-tier application architecture

You should also be comfortable with:

* Command-line text manipulation (<code>grep</code>, <code>awk</code>, <code>cut</code>, <code>sed</code>)
* Basic bash scripting (variables, loops, conditionals)
* Using multiple terminal windows simultaneously


== Theoretical Background ==


=== Linux Namespaces: The Foundation of Containers ===

In Labs 7-9, you worked extensively with network namespaces—one of seven namespace types provided by the Linux kernel. Every time you executed:

<syntaxhighlight lang="bash">sudo ip netns add red
sudo ip netns exec red ip addr show</syntaxhighlight>
You were creating an isolated network environment and executing commands within that isolated environment. The processes running in the <code>red</code> namespace could not see network interfaces, routes, or connections in other namespaces. This isolation is the fundamental mechanism that makes containers possible.

Docker extends this concept to six additional namespace types, providing complete process isolation. Understanding namespaces is essential to understanding containers—they are not optional background knowledge, but rather the core technology that defines what a container is.


==== The Seven Namespace Types ====

'''1. Network Namespace (<code>net</code>)'''

You know this namespace intimately from Labs 7-9. When you created the <code>red</code> and <code>blue</code> namespaces, you were creating isolated network stacks.

'''What it isolates:'''

* Network interfaces (lo, eth0, wlan0, etc.)
* IP addresses (each namespace has its own IPs)
* Routing tables (<code>ip route show</code> output differs per namespace)
* Firewall rules (iptables/nftables rules are namespace-specific)
* Network sockets and ports (multiple processes in different namespaces can bind to the same port number)

'''Connection to Lab 7:'''

In Lab 7, you manually created network namespaces:

<syntaxhighlight lang="bash">sudo ip netns add red # Create isolated network stack
sudo ip netns exec red ip link show # View interfaces in that namespace</syntaxhighlight>
Docker does exactly this when you run a container, but also creates six other namespace types simultaneously.

'''Example implications:'''

* Container A can listen on port 80, Container B can listen on port 80—no conflict
* Container A cannot see Container B's network connections (<code>ss -tuna</code> shows only its own)
* Each container has its own localhost (127.0.0.1) that's separate from the host

'''2. PID Namespace (<code>pid</code>)'''

The PID namespace isolates the process ID number space. This is related to what you learned in Lab 3 about process management.

'''What it isolates:'''

* Process IDs—processes in different PID namespaces can have the same PID
* Process visibility—processes can only see other processes in the same PID namespace
* PID 1 (init process)—each PID namespace has its own PID 1

'''How it works:'''

The kernel maintains a separate process tree for each PID namespace. When you create a PID namespace and start a process in it:

* Inside the namespace, that process is PID 1 (like an init system)
* Outside the namespace, that same process has a different PID (e.g., 12345)
* Processes inside cannot see processes outside their namespace tree

'''Example:'''

<syntaxhighlight lang="bash"># On the host
ps aux | wc -l
# Output: 237 processes

# Inside a container
docker exec container ps aux | wc -l
# Output: 5 processes</syntaxhighlight>
The container's processes think they're the only processes on the system. They cannot see the host's other 232 processes.

'''3. Mount Namespace (<code>mnt</code>)'''

The mount namespace isolates the filesystem mount table. This relates directly to Lab 2 where you learned about filesystems and mounting.

'''What it isolates:'''

* Mount points—what is mounted at <code>/</code>, <code>/tmp</code>, <code>/var</code>, etc.
* Root filesystem—each namespace can have a completely different root directory
* Mount propagation—mounts in one namespace don't affect others (by default)

'''How it works:'''

When you create a mount namespace, the new namespace inherits a copy of the parent's mount table. But subsequent mounts/unmounts in the child don't affect the parent.

Containers use this to provide a completely different filesystem:

<syntaxhighlight lang="bash"># On host (Ubuntu)
ls /
bin boot dev etc home lib ...

# In container (Fedora)
docker exec fedora ls /
bin boot dev etc home lib ... # Different files!</syntaxhighlight>
Both see <code>/etc</code>, but they're seeing different directories. The container's <code>/etc/os-release</code> shows Fedora, while the host's shows Ubuntu.

'''Technical implementation:'''

Docker uses OverlayFS (covered later) to construct the container's root filesystem from image layers, then uses pivot_root or chroot to make that directory appear as <code>/</code> to the container's processes.

'''4. UTS Namespace (<code>uts</code>)'''

UTS stands for "Unix Timesharing System"—a historical name. The UTS namespace isolates hostname and domain name.

'''What it isolates:'''

* System hostname (<code>hostname</code> command output)
* Domain name (NIS domain name)

'''How it works:'''

Each UTS namespace can set its own hostname independently of other namespaces.

<syntaxhighlight lang="bash"># On host
hostname
# Output: myserver.example.com

# In container
docker exec container hostname
# Output: a1b2c3d4e5f6 (container ID)</syntaxhighlight>
Containers typically use the container ID as hostname by default, but you can override with <code>--hostname</code>:

<syntaxhighlight lang="bash">docker run --hostname=webserver nginx</syntaxhighlight>
'''5. IPC Namespace (<code>ipc</code>)'''

The IPC namespace isolates System V Inter-Process Communication resources. This relates to Lab 6 where you learned about IPC mechanisms.

'''What it isolates:'''

* System V message queues
* System V semaphore sets
* System V shared memory segments
* POSIX message queues (in <code>/dev/mqueue</code>)

'''Connection to Lab 6:'''

In Lab 6, you learned that processes can communicate via shared memory, message queues, and semaphores. The IPC namespace ensures that processes in different namespaces cannot access each other's IPC objects, even if they use the same IPC keys.

'''Example:'''

<syntaxhighlight lang="bash"># Container A creates shared memory segment with key 1234
docker exec containerA ipcmk -M 1024 -p 1234

# Container B tries to access it
docker exec containerB ipcs -m -k 1234
# Output: no segment found (different IPC namespace)</syntaxhighlight>
'''6. User Namespace (<code>user</code>)'''

The user namespace isolates user IDs (UIDs) and group IDs (GIDs). This is the most complex namespace and provides significant security benefits.

'''What it isolates:'''

* User IDs—UID 0 inside namespace can map to UID 100000 outside
* Group IDs—similar mapping for GIDs
* Capabilities—process can have capabilities inside namespace but not outside
* Security attributes—AppArmor/SELinux contexts

'''How it works:'''

User namespaces allow UID/GID mapping. A process can be root (UID 0) inside the namespace but unprivileged (e.g., UID 100000) outside.

<pre>Inside Container: UID 0 (root)
↓ mapping
Outside Container: UID 100000 (unprivileged)</pre>
'''Security benefit:'''

Even if an attacker compromises a container and gains root privileges inside the container, they're still unprivileged on the host. If they escape the container, they cannot access files owned by actual root.

'''Docker's approach:'''

By default, many Docker configurations share the host's user namespace (for simplicity and compatibility). Rootless Docker and user-remapped Docker use separate user namespaces for enhanced security.

'''7. Cgroup Namespace (<code>cgroup</code>)'''

The cgroup namespace isolates the view of the cgroup hierarchy. Note this is different from cgroups themselves (which we'll cover separately).

'''What it isolates:'''

* View of <code>/proc/self/cgroup</code>
* View of <code>/sys/fs/cgroup</code> hierarchy
* Ability to see other containers' resource constraints

'''How it works:'''

Without cgroup namespaces, a process can read <code>/proc/self/cgroup</code> and see the full path to its cgroup, revealing information about the container orchestration system.

With cgroup namespaces, the process sees itself at the root of the cgroup tree, hiding the real hierarchy.

'''Note:''' This namespace isolates the ''view'' of cgroups, not the enforcement of resource limits. Resource limits are enforced by cgroups themselves (covered in section 4.5).


==== Namespace Identifiers: Understanding /proc/PID/ns/ ====

Every process has a directory at <code>/proc/PID/ns/</code> containing symbolic links to namespace identifiers. These links reveal which namespaces the process belongs to.

'''Examining namespace identifiers:'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/</syntaxhighlight>
'''Example output:'''

<pre>lrwxrwxrwx 1 root root 0 Dec 12 10:30 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 net -> 'net:[4026531992]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 uts -> 'uts:[4026531838]'</pre>
'''Understanding the format:'''

Each symlink follows the pattern: <code>namespace_type:[inode_number]</code>

The '''inode number''' is the critical piece of information. It uniquely identifies that specific namespace instance. Think of it as a "namespace ID."

'''Key principle: Same inode = Shared namespace, Different inode = Isolated namespace'''

'''Example from Lab 7:'''

When you created network namespaces in Lab 7, each had a unique network namespace inode:

<syntaxhighlight lang="bash"># Host process
sudo ls -la /proc/$$/ns/net
net -> 'net:[4026531992]' # Host's network namespace

# Process in red namespace
sudo ip netns exec red ls -la /proc/$$/ns/net
net -> 'net:[4026532145]' # Different inode = isolated!

# Process in blue namespace
sudo ip netns exec blue ls -la /proc/$$/ns/net
net -> 'net:[4026532147]' # Also different = also isolated!</syntaxhighlight>
'''Comparing container to host:'''

<syntaxhighlight lang="bash"># Get container's PID on host
docker inspect container --format '{{.State.Pid}}'
# Example output: 12345

# View container's namespaces
sudo ls -la /proc/12345/ns/net
# Output: net -> 'net:[4026533672]'

# View host's namespace
sudo ls -la /proc/$$/ns/net
# Output: net -> 'net:[4026531992]'

# Different inodes! Container is isolated.</syntaxhighlight>
'''Namespace sharing:'''

Sometimes containers intentionally share namespaces. For example:

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
This container shares the host's network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]' # Same as host!</syntaxhighlight>
'''Using namespace identifiers:'''

These symlinks aren't just informational—you can actually use them to enter namespaces:

<syntaxhighlight lang="bash">sudo nsenter --net=/proc/12345/ns/net ip addr show</syntaxhighlight>
This command enters the network namespace of PID 12345 and runs <code>ip addr show</code> inside that namespace. This is how <code>docker exec</code> works under the hood—it uses <code>nsenter</code> to join the container's namespaces.

'''Summary table:'''

{| class="wikitable"
|-
! Namespace Type
! What It Isolates
! Lab Connection
|-
| <code>net</code>
| Network stack (interfaces, IPs, routes, ports)
| Lab 7: You built this manually!
|-
| <code>pid</code>
| Process IDs and process tree
| Lab 3: Process management
|-
| <code>mnt</code>
| Filesystem mounts and root directory
| Lab 2: Mounting and filesystems
|-
| <code>uts</code>
| Hostname and domain name
| -
|-
| <code>ipc</code>
| Shared memory, message queues, semaphores
| Lab 6: IPC mechanisms
|-
| <code>user</code>
| User and group IDs, capabilities
| Lab 4: Users and permissions
|-
| <code>cgroup</code>
| View of cgroup hierarchy
| -
|}


=== Container Images vs Running Containers ===

This distinction is fundamental to understanding Docker and is often a source of confusion.

'''Container Image:'''

A container image is a '''read-only template''' consisting of:

# '''A root filesystem''': All files and directories that will appear in the container (applications, libraries, configuration files)
# '''Metadata''': Information about how to run the container (default command, environment variables, exposed ports, volumes)
# '''Layers''': The filesystem is composed of multiple read-only layers (explained in section 4.4)

'''Characteristics:'''

* '''Immutable''': Once built, an image never changes
* '''Shareable''': Multiple containers can use the same image
* '''Versionable''': Images can have tags (e.g., <code>nginx:1.21</code>, <code>nginx:latest</code>)
* '''Distributable''': Images can be pushed to/pulled from registries (Docker Hub, private registries)
* '''Stored on disk''': Images consume storage even when not running

'''Running Container:'''

A running container is an '''instance''' of an image—a process (or process tree) running in isolated namespaces with its own writable filesystem layer.

'''Characteristics:'''

* '''Ephemeral''': State is lost when the container is removed (unless using volumes)
* '''Mutable''': Can make changes inside the container (install packages, create files)
* '''Process-based''': A container is fundamentally just a Linux process in isolated namespaces
* '''Short-lived''': Containers are typically created, used, and destroyed frequently
* '''Stateful during runtime''': Maintains state while running, but that state disappears on removal

'''Example to illustrate:'''

<syntaxhighlight lang="bash"># Pull an image (download the template)
docker pull nginx

# The image now exists on disk
docker images
# Output shows: nginx latest a1b2c3d4 100MB

# Start first container from this image
docker run -d --name web1 nginx

# Start second container from the same image
docker run -d --name web2 nginx

# Both containers share the same base image filesystem
# But each has its own writable layer and separate namespaces</syntaxhighlight>
Now you have:

* '''One image''' (nginx:latest) on disk
* '''Two containers''' (web1 and web2) running as separate processes
* Each container has its own PID namespace, network namespace, etc.
* Changes in web1 don't affect web2 (isolated writable layers)

'''Verification:'''

<syntaxhighlight lang="bash"># Modify web1
docker exec web1 bash -c "echo 'Hello from web1' > /usr/share/nginx/html/test.txt"

# Check web1
docker exec web1 cat /usr/share/nginx/html/test.txt
# Output: Hello from web1

# Check web2
docker exec web2 cat /usr/share/nginx/html/test.txt
# Output: cat: /usr/share/nginx/html/test.txt: No such file or directory</syntaxhighlight>
The file exists in web1 but not in web2, even though they're from the same image. Each container has its own writable layer.

'''Image to Container Relationship Diagram:'''

<pre> [nginx Image]
(Read-only)
|
┌─────────┴─────────┐
↓ ↓
[Container 1] [Container 2]
(Writable layer) (Writable layer)
(PID namespace) (PID namespace)
(Net namespace) (Net namespace)
(Isolated) (Isolated)</pre>
'''Filesystem perspective:'''

<pre>Image Layers (read-only, shared):
├─ Layer 3: nginx files
├─ Layer 2: nginx dependencies
└─ Layer 1: Base OS (Debian)

Container 1 (writable, unique):
└─ Writable layer: Changes made in container 1

Container 2 (writable, unique):
└─ Writable layer: Changes made in container 2</pre>
'''Why this design?'''

* '''Efficiency''': 100 containers from the same image share one copy of the base filesystem
* '''Speed''': Starting a container doesn't require copying files—just create a new writable layer
* '''Consistency''': All containers from an image start with identical state
* '''Immutability''': Encourages treating containers as disposable—don't modify running containers, rebuild images instead


=== Container Lifecycle and Ephemeral Nature ===

Understanding the container lifecycle is essential for proper container usage. Containers are designed to be ephemeral—short-lived and replaceable.

'''Container States:'''

<pre>┌─────────┐
│ Created │ (Container exists but not running)
└────┬────┘
│ docker start
↓
┌─────────┐
│ Running │ (Processes executing in isolated namespaces)
└────┬────┘
│ docker stop (SIGTERM, then SIGKILL after timeout)
↓
┌─────────┐
│ Stopped │ (Processes terminated, filesystem layer persists)
└────┬────┘
│ docker start (restart with same writable layer)
↓
┌─────────┐
│ Running │
└────┬────┘
│ docker rm (delete container)
↓
┌─────────┐
│ Removed │ (Container and writable layer deleted forever)
└─────────┘</pre>
'''Key lifecycle commands:'''

<syntaxhighlight lang="bash"># Create and start in one step (most common)
docker run nginx

# Create without starting
docker create --name test nginx

# Start existing stopped container
docker start test

# Stop running container (SIGTERM to main process)
docker stop test

# Force stop (SIGKILL)
docker kill test

# Remove stopped container
docker rm test

# Remove running container (force)
docker rm -f test</syntaxhighlight>
'''The Ephemeral Nature:'''

By default, all changes made inside a container are lost when the container is removed:

<syntaxhighlight lang="bash"># Start container
docker run -d --name demo nginx

# Make changes inside
docker exec demo bash -c "echo 'My data' > /tmp/important.txt"
docker exec demo cat /tmp/important.txt
# Output: My data

# Stop and remove container
docker stop demo
docker rm demo

# Try to access the data
docker run --name demo2 nginx
docker exec demo2 cat /tmp/important.txt
# Output: cat: /tmp/important.txt: No such file or directory
# THE DATA IS GONE!</syntaxhighlight>
'''Why ephemeral?'''

This might seem like a limitation, but it's actually a feature that enables important practices:

# '''Immutable Infrastructure''': Don't patch running systems; deploy new versions
# '''Reproducibility''': Every deployment starts from a known state
# '''Testing''': Test environments are identical to production
# '''Rollback''': Easy to roll back to previous image version
# '''Scaling''': Identical containers can be created/destroyed dynamically

'''When you need persistence:'''

For data that must survive container restarts, use '''volumes''' (covered in section 4.7):

<syntaxhighlight lang="bash"># Create named volume
docker volume create mydata

# Use volume in container
docker run -v mydata:/data nginx

# Data in /data survives container removal</syntaxhighlight>
'''Container lifecycle best practices:'''

* '''Treat containers as cattle, not pets''': Don't name them, don't SSH into them to debug, don't manually configure them
* '''Logs go to stdout/stderr''': Not to files inside the container (so <code>docker logs</code> can capture them)
* '''Configuration via environment variables''': Not by editing files inside the container
* '''Data goes in volumes''': Not in the container's writable layer
* '''Short-lived processes''': Containers should start quickly and shut down gracefully

'''Connection to Lab 3:'''

In Lab 3, you learned about process lifecycle (start, run, terminate). Containers follow a similar lifecycle, but operate at a higher level of abstraction—each container lifecycle event actually involves creating/destroying multiple processes in isolated namespaces.


=== Control Groups (cgroups): Resource Limiting ===

Control groups (cgroups) are a Linux kernel feature that limits, accounts for, and isolates resource usage (CPU, memory, disk I/O, network) of process groups. Without cgroups, a runaway container could consume all CPU or memory, starving other containers and crashing the host.

'''The Problem:'''

Without resource limits:

<syntaxhighlight lang="bash"># Malicious or buggy container
docker run -d evil-container

# This container's process could:
# - Consume 100% CPU (slow down everything else)
# - Allocate all available RAM (trigger OOM killer on host)
# - Fill up disk space (crash other containers)
# - Monopolize network bandwidth</syntaxhighlight>
This is unacceptable in multi-tenant environments. You need resource isolation.

'''The Solution: cgroups'''

Cgroups organize processes into hierarchical groups with configurable resource limits. The kernel enforces these limits, preventing processes from exceeding their allocation.

'''Cgroup Controllers:'''

The Linux kernel provides several cgroup controllers, each managing a different resource type:

# '''cpu''': Limits CPU time
#* CPU shares (relative priority)
#* CPU quotas (hard limits)
#* CPU affinity (pin to specific cores)
# '''memory''': Limits RAM usage
#* Hard limits (container killed if exceeded)
#* Soft limits (reclaim memory under pressure)
#* Swap limits
# '''blkio''': Limits disk I/O
#* Read/write bandwidth limits
#* I/O operation rate limits
# '''net_cls/net_prio''': Network bandwidth control
#* Traffic classification
#* Priority settings
# '''pids''': Limits number of processes
#* Prevents fork bombs
# '''cpuset''': Assigns specific CPUs and memory nodes
#* NUMA awareness

'''Docker's cgroup integration:'''

When you start a container with resource limits, Docker configures the appropriate cgroups:

<syntaxhighlight lang="bash">docker run --memory=512m --cpus=1.5 nginx</syntaxhighlight>
Docker creates a cgroup hierarchy at <code>/sys/fs/cgroup/</code> and configures:

* <code>memory.limit_in_bytes = 536870912</code> (512MB)
* <code>cpu.cfs_quota_us</code> and <code>cpu.cfs_period_us</code> to enforce 1.5 CPUs

'''Viewing cgroup settings:'''

<syntaxhighlight lang="bash"># Get container's PID
docker inspect container --format '{{.State.Pid}}'
# Example: 12345

# View memory limit
cat /sys/fs/cgroup/memory/docker/12345/memory.limit_in_bytes
# Output: 536870912

# View CPU quota
cat /sys/fs/cgroup/cpu/docker/12345/cpu.cfs_quota_us
# Output: 150000 (1.5 CPUs)</syntaxhighlight>
'''Common resource limit flags:'''

<syntaxhighlight lang="bash"># Memory limits
--memory=512m # Hard limit: 512MB RAM
--memory-reservation=256m # Soft limit: try to stay under 256MB
--memory-swap=512m # Total memory+swap limit

# CPU limits
--cpus=1.5 # Use at most 1.5 CPU cores
--cpu-shares=512 # Relative CPU priority (default 1024)
--cpuset-cpus=0,1 # Pin to CPU cores 0 and 1

# I/O limits
--device-read-bps=/dev/sda:10mb # Limit read bandwidth
--device-write-bps=/dev/sda:10mb # Limit write bandwidth

# Process limits
--pids-limit=100 # Max 100 processes in container</syntaxhighlight>
'''Testing memory limits:'''

<syntaxhighlight lang="bash"># Run container with 256MB memory limit
docker run -it --memory=256m ubuntu bash

# Inside container, try to allocate 512MB
# (requires 'stress' tool)
apt-get update && apt-get install -y stress
stress --vm 1 --vm-bytes 512M

# Container is killed when exceeding limit
# Output: stress: FAIL: [1] (415) <-- worker 7 got signal 9
# Signal 9 = SIGKILL (OOM killer)</syntaxhighlight>
'''Why cgroups are essential:'''

# '''Multi-tenancy''': Run untrusted workloads safely
# '''Quality of Service''': Guarantee resources for critical applications
# '''Fair sharing''': Prevent one container from monopolizing resources
# '''Predictability''': Know exactly how much resources each container can use
# '''Cost control''': In cloud environments, map cgroups to billing

'''cgroup vs namespace distinction:'''

* '''Namespaces''': Provide ''isolation''
* '''cgroups''': Provide ''resource limits''

Both are necessary for containers. Namespaces prevent containers from seeing each other; cgroups prevent containers from starving each other.


=== Docker Networking: Bridges, veth Pairs, and NAT ===

Docker networking should feel familiar—it uses the exact same mechanisms you built manually in Lab 7. The primary difference is automation: Docker sets up bridges, veth pairs, routes, and NAT rules automatically.

'''Default Docker Network Architecture:'''

When you install Docker, it creates a default bridge network:

<pre>┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Container A │ │ Container B │ │ Container C │
│ 172.17.0.2 │ │ 172.17.0.3 │ │ 172.17.0.4 │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│eth0 │eth0 │eth0
│ │ │
(veth pair) (veth pair) (veth pair)
│ │ │
┌────┴───────────────────┴───────────────────┴────┐
│ docker0 Bridge │
│ 172.17.0.1/16 │
└────────────────────┬─────────────────────────────┘
│
[Host eth0]
│
[Internet]
(via NAT/MASQUERADE)</pre>
'''Component breakdown (all from Lab 7!):'''

'''1. Bridge Interface (<code>docker0</code>)'''

Docker automatically creates a bridge interface when installed:

<syntaxhighlight lang="bash">ip addr show docker0</syntaxhighlight>
'''Expected output:'''

<pre>3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 02:42:8f:a3:f1:2a brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0</pre>
This is '''exactly like <code>br-lab</code>''' from Lab 7:

* Bridge interface acting as virtual switch
* Assigned IP address 172.17.0.1
* Subnet 172.17.0.0/16 (65,536 addresses available)

'''2. veth Pairs'''

For each container, Docker creates a veth pair:

<syntaxhighlight lang="bash">ip link show | grep veth</syntaxhighlight>
'''Expected output:'''

<pre>8: veth7a3f2b1@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0
10: veth9d4e8c2@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0</pre>
'''Decoding this:'''

* <code>veth7a3f2b1@if7</code>: One end of veth pair, connected to bridge (<code>master docker0</code>)
* <code>@if7</code>: Paired with interface index 7 (inside container)

This is '''exactly what you did in Lab 7:'''

<syntaxhighlight lang="bash">sudo ip link add v-host type veth peer name v-client</syntaxhighlight>
Docker does the same thing, automatically.

'''3. Container Network Namespace'''

Each container has its own network namespace (you built these manually in Lab 7!):

<syntaxhighlight lang="bash"># View container's network interfaces
docker exec container ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo

7: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0</pre>
The container sees:

* <code>lo</code>: Its own loopback interface
* <code>eth0@if8</code>: Its end of the veth pair (paired with host's interface index 8)
* IP address from docker0 subnet

'''4. IP Address Assignment'''

Docker acts as a simple DHCP-like service, assigning IPs sequentially:

* First container: 172.17.0.2
* Second container: 172.17.0.3
* Third container: 172.17.0.4
* etc.

'''5. Routing in Container'''

Check the container's routing table:

<syntaxhighlight lang="bash">docker exec container ip route show</syntaxhighlight>
'''Expected output:'''

<pre>default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2</pre>
'''Translation:'''

* Default route: Send all traffic to 172.17.0.1 (the bridge) for routing to internet
* Local route: 172.17.0.0/16 is directly reachable via eth0

This is '''exactly the routing you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo ip netns exec red ip route add default via 10.0.0.1</syntaxhighlight>
'''6. NAT for Internet Access'''

Docker automatically configures iptables/nftables NAT rules (MASQUERADE) so containers can reach the internet:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep MASQUERADE</syntaxhighlight>
'''Expected output:'''

<pre>MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0</pre>
This is '''exactly the NAT you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE</syntaxhighlight>
'''7. Port Mapping (<code>-p</code> flag)'''

When you use <code>-p 8080:80</code>, Docker sets up Destination NAT (DNAT):

<syntaxhighlight lang="bash">docker run -d -p 8080:80 nginx</syntaxhighlight>
Docker adds an iptables DNAT rule:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep DNAT</syntaxhighlight>
'''Expected output:'''

<pre>DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80</pre>
'''Translation:''' Traffic arriving at host port 8080 is redirected to 172.17.0.2:80

This is also NAT, specifically DNAT (Destination NAT). You encountered source NAT (SNAT/MASQUERADE) in Lab 7.

'''Container-to-Container Communication'''

Containers on the same bridge can communicate directly:

<syntaxhighlight lang="bash"># Container A pings Container B
docker exec containerA ping 172.17.0.3</syntaxhighlight>
The packet flow:

# Container A sends to 172.17.0.2 (Container B's IP)
# Packet goes out Container A's eth0 (through veth pair)
# Arrives on docker0 bridge
# Bridge forwards to veth pair for Container B
# Packet arrives at Container B's eth0

'''No routing through host networking needed'''—the bridge forwards directly (Layer 2 switching).

'''Custom Networks'''

You can create custom bridge networks:

<syntaxhighlight lang="bash">docker network create --subnet=10.20.0.0/24 mynet</syntaxhighlight>
Docker creates a new bridge interface (e.g., <code>br-abc123def456</code>) with subnet 10.20.0.0/24.

Containers on different networks are isolated:

<syntaxhighlight lang="bash">docker run -d --network=mynet --name=isolated nginx</syntaxhighlight>
This container is on <code>mynet</code>, not <code>docker0</code>, so it cannot communicate with containers on the default bridge (different Layer 2 segment).

'''DNS Resolution Between Containers'''

Docker provides automatic DNS resolution for container names within custom networks:

<syntaxhighlight lang="bash">docker network create mynet
docker run -d --network=mynet --name=web nginx
docker run -d --network=mynet --name=app alpine

# From app container
docker exec app ping web
# Resolves 'web' to web container's IP address!</syntaxhighlight>
Docker runs an embedded DNS server (listening on 127.0.0.11 inside containers) that resolves container names to IPs.

'''Network Modes:'''

Docker supports several network modes:

* '''bridge''' (default): Container on docker0 bridge (or custom bridge)
* '''host''': Container shares host's network namespace (no isolation)
* '''none''': No networking (container has only loopback)
* '''container:name''': Share another container's network namespace

'''Example: host mode'''

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
The container's network namespace inode is the same as the host's:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]' # Same as host!</syntaxhighlight>
Container sees all host's network interfaces and can bind to any port on any interface.

'''Summary:'''

Docker networking uses:

* Bridges (like <code>br-lab</code> from Lab 7)
* veth pairs (like <code>v-host</code> ↔ <code>v-client</code> from Lab 7)
* Network namespaces (like <code>red</code> and <code>blue</code> from Lab 7)
* Routing tables and default routes
* NAT/MASQUERADE for internet access
* DNAT for port mapping


=== Volumes: Persistent and Shared Storage ===

By default, container filesystems are ephemeral—all changes are lost when the container is removed. For data that must persist (databases, user uploads, logs), Docker provides volumes.

'''The Problem:'''

<syntaxhighlight lang="bash"># Start database container
docker run -d --name db postgres

# Database writes data
docker exec db psql -c "CREATE DATABASE myapp;"

# Stop and remove container
docker rm -f db

# Data is GONE FOREVER!</syntaxhighlight>
This is unacceptable for stateful applications.

'''The Solution: Volumes'''

Volumes are directories on the host that are mounted into containers. Data written to volumes persists beyond container lifecycle.

'''Two Volume Types:'''

'''1. Named Volumes (Docker-managed):'''

Docker manages the volume storage location.

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# Use in container
docker run -v mydata:/data nginx

# Data written to /data inside container is stored in:
# /var/lib/docker/volumes/mydata/_data (on host)</syntaxhighlight>
'''Advantages:'''

* Docker manages storage location
* Portable across hosts (can be backed up, restored)
* Works with volume plugins (NFS, cloud storage)

'''Best practice:''' Use named volumes for production databases, critical data.

'''2. Bind Mounts (Host directory):'''

Mount a host directory directly into the container.

<syntaxhighlight lang="bash"># Mount host directory into container
docker run -v /home/user/html:/usr/share/nginx/html nginx</syntaxhighlight>
Any changes in <code>/home/user/html</code> on the host are immediately visible in <code>/usr/share/nginx/html</code> inside the container, and vice versa.

'''Advantages:'''

* Direct access to files from host
* Useful for development (edit code on host, see changes in container immediately)
* No Docker management needed

'''Disadvantages:'''

* Tied to specific host filesystem paths
* Less portable
* Permissions can be tricky (host UID vs. container UID)

<syntaxhighlight lang="bash"># Docker essentially does:
mount --bind /var/lib/docker/volumes/mydata/_data /data</syntaxhighlight>
'''Volume Sharing Between Containers:'''

Multiple containers can share the same volume:

<syntaxhighlight lang="bash"># Create volume
docker volume create shared

# Container 1 writes
docker run -v shared:/data --name writer alpine sh -c "echo 'Hello' > /data/file.txt"

# Container 2 reads
docker run -v shared:/data --name reader alpine cat /data/file.txt
# Output: Hello</syntaxhighlight>
'''Use cases:'''

* Shared configuration between containers
* Log aggregation (multiple containers write logs to shared volume)
* Data processing pipelines (one container produces, another consumes)

'''Volume Lifecycle:'''

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# List volumes
docker volume ls

# Inspect volume
docker volume inspect mydata

# Remove volume (only if no containers using it)
docker volume rm mydata

# Remove all unused volumes
docker volume prune</syntaxhighlight>
'''Inspecting Volume Mounts:'''

<syntaxhighlight lang="bash">docker inspect container --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Example output:'''

<syntaxhighlight lang="json">[
{
"Type": "volume",
"Source": "/var/lib/docker/volumes/mydata/_data",
"Destination": "/data",
"Mode": "z",
"RW": true
}
]</syntaxhighlight>
'''Fields:'''

* <code>Type</code>: "volume" or "bind"
* <code>Source</code>: Host-side path
* <code>Destination</code>: Container-side path
* <code>RW</code>: Read-write (true) or read-only (false)

'''Read-Only Volumes:'''

For security, you can mount volumes read-only:

<syntaxhighlight lang="bash">docker run -v mydata:/data:ro nginx</syntaxhighlight>
Container can read <code>/data</code> but cannot write to it.

'''tmpfs Mounts (In-Memory Temporary Storage):'''

For sensitive data that should never touch disk:

<syntaxhighlight lang="bash">docker run --tmpfs /tmp:size=100m nginx</syntaxhighlight>
The <code>/tmp</code> directory is stored in RAM and disappears when the container stops.

'''Best Practices:'''

* '''Named volumes for databases''': Postgres, MySQL, MongoDB
* '''Bind mounts for development''': Code that you're actively editing
* '''tmpfs for secrets''': Temporary credentials, keys
* '''Volume plugins for cloud''': AWS EBS, Azure Disk, GCP Persistent Disk


== Laboratory Exercises ==

The following exercises build progressively, demonstrating how Docker automates the kernel-level primitives you mastered in previous labs. You will install Docker, inspect namespace isolation, explore interactive containers, configure persistent storage, and build a multi-container application with networking and resource limits.


=== Exercise A: Installing Docker ===

'''Objective:''' Install Docker Engine from the official Docker repository and configure it for non-root access.

'''Why the official repository?''' Ubuntu's default repositories often contain outdated Docker versions. The official Docker repository provides the latest stable releases with security updates and new features.

'''Step 1: Remove old Docker versions (if any)'''

If you previously installed Docker from Ubuntu's repositories or older Docker installations exist, remove them to avoid conflicts:

<syntaxhighlight lang="bash">sudo apt remove docker docker-engine docker.io containerd runc</syntaxhighlight>
It's safe to run this even if these packages aren't installed—apt will simply report they're not present.

'''Step 2: Install prerequisites'''

Install packages needed for adding Docker's repository:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg \
lsb-release</syntaxhighlight>
'''Step 3: Add Docker's GPG key'''

Docker signs its packages with a GPG key to ensure authenticity. Add this key to your system:

<syntaxhighlight lang="bash">sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg</syntaxhighlight>
'''What this does:'''

* Creates <code>/etc/apt/keyrings/</code> directory for storing repository keys
* Downloads Docker's GPG public key
* Converts it to binary format (<code>.gpg</code> file)
* Makes it readable by all users

'''Step 4: Add Docker repository to apt sources'''

<syntaxhighlight lang="bash">sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.gpg
EOF</syntaxhighlight>
'''What this does:'''

* Detects your CPU architecture (amd64, arm64, etc.)
* Detects your Ubuntu version codename (focal, jammy, etc.)
* Adds Docker's repository to apt's source list

'''Step 5: Install Docker Engine'''

Update package index and install Docker:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
docker-ce \
docker-ce-cli \
containerd.io \
docker-buildx-plugin \
docker-compose-plugin</syntaxhighlight>
'''Packages installed:'''

* <code>docker-ce</code>: Docker Community Edition engine (the main Docker daemon)
* <code>docker-ce-cli</code>: Docker command-line interface
* <code>containerd.io</code>: Container runtime that Docker uses under the hood
* <code>docker-buildx-plugin</code>: Extended build capabilities (multi-platform images)
* <code>docker-compose-plugin</code>: Docker Compose for multi-container applications

'''Step 6: Verify Docker installation'''

Check Docker version:

<syntaxhighlight lang="bash">sudo docker --version</syntaxhighlight>
'''Expected output:'''

<pre>Docker version 24.0.7, build afdd53b</pre>
Your version number may be different (newer), which is fine.

'''Step 7: Start and enable Docker service'''

Ensure Docker daemon starts on boot:

<syntaxhighlight lang="bash">sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
Check service status:

<syntaxhighlight lang="bash">sudo systemctl status docker</syntaxhighlight>
'''Expected output:'''

<pre>● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled)
Active: active (running) since Thu 2024-12-12 10:30:00 UTC; 5min ago</pre>
Look for <code>Active: active (running)</code>.

'''Step 8: Configure non-root Docker access'''

By default, only root can run Docker commands. To run Docker without <code>sudo</code>, add your user to the <code>docker</code> group:

<syntaxhighlight lang="bash">sudo usermod -aG docker $USER</syntaxhighlight>
'''Important:''' Log out and log back in for this change to take effect. Alternatively, you can run:

<syntaxhighlight lang="bash">newgrp docker</syntaxhighlight>
This starts a new shell with updated group membership.

'''Step 9: Verify non-root access'''

Test that you can run Docker without sudo:

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
If this works without errors, you've successfully installed Docker!

'''Expected output:'''

<pre>Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:4bd78111b6914a99dbc560e6a20eab57ff6655aea4a80c50b0c5491968cbc2e6
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/</pre>
'''What happened:'''

# Docker client (<code>docker</code> command) connected to Docker daemon (dockerd)
# Daemon checked local images—didn't find <code>hello-world</code>
# Daemon pulled <code>hello-world</code> image from Docker Hub (public registry)
# Daemon created container from image
# Container executed its program (printed the message)
# Container exited
# Output sent back to your terminal

'''Step 10: Clean up test container'''

List all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
You should see the hello-world container with status <code>Exited (0)</code>.

Remove it:

<syntaxhighlight lang="bash">docker rm $(docker ps -aq --filter "ancestor=hello-world")</syntaxhighlight>
Verify it's gone:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Deliverable A:'''

Provide screenshots showing:

# Output of <code>docker --version</code>
# Output of <code>sudo systemctl status docker</code> (showing Active: active (running))
# Output of <code>docker run hello-world</code> (the entire message)



=== Exercise B: Hello World and Namespace Inspection ===

'''Objective:''' Run your first container, understand the container lifecycle, and inspect the Linux kernel namespaces that provide container isolation—connecting directly to your work in Lab 7.


==== Part 1: Hello World ====

'''Step 1: Run the hello-world container (if not done in Exercise A)'''

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
We covered this in Exercise A, but let's examine what actually happened in more detail.

'''Step 2: List all containers'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:''' Nothing (empty list)

'''Why?''' The hello-world container ran, printed its message, and exited immediately. <code>docker ps</code> only shows running containers by default.

To see all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 hello-world "/hello" 10 seconds ago Exited (0) 8 seconds ago eager_tesla</pre>
'''Understanding the fields:'''

* '''CONTAINER ID''': Short hex identifier (first 12 chars of full 64-char ID)
* '''IMAGE''': Which image this container was created from
* '''COMMAND''': The process that ran inside the container (<code>/hello</code> executable)
* '''CREATED''': When the container was created
* '''STATUS''': Current state—<code>Exited (0)</code> means process exited with code 0 (success)
* '''PORTS''': Port mappings (none for hello-world)
* '''NAMES''': Random name if you don't specify one (Docker generates names like "eager_tesla", "hopeful_darwin")

'''Step 3: Inspect the container'''

Get detailed information about the container:

<syntaxhighlight lang="bash">docker inspect eager_tesla # Use your actual container name</syntaxhighlight>
This outputs a large JSON document with all container metadata. Let's extract specific fields:

<syntaxhighlight lang="bash"># Just the State section
docker inspect eager_tesla --format='{{json .State}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output (formatted):'''

<syntaxhighlight lang="json">{
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 0,
"StartedAt": "2024-12-12T10:35:00Z",
"FinishedAt": "2024-12-12T10:35:01Z"
}</syntaxhighlight>
'''Analysis:'''

* Container ran for about 1 second (started at :00, finished at :01)
* Exit code 0 (successful completion)
* PID is 0 (process has terminated; while running it had a real PID)

'''Step 4: View container logs'''

Even though the container exited, Docker saved its output:

<syntaxhighlight lang="bash">docker logs eager_tesla</syntaxhighlight>
Shows the hello-world message again. This demonstrates that Docker captures stdout/stderr from containers.

'''Step 5: Remove the container'''

Stopped containers still consume disk space (their writable layer persists). Remove it:

<syntaxhighlight lang="bash">docker rm eager_tesla</syntaxhighlight>
Verify removal:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
The container should be gone.


==== Part 2: Inspect Namespaces (Connect to Lab 7!) ====

Now let's run a longer-lived container and examine its namespace isolation—this directly connects to your hands-on work with network namespaces in Lab 7.

'''Step 1: Run a persistent container'''

<syntaxhighlight lang="bash">docker run -d --name inspector nginx</syntaxhighlight>
'''Flags explained:'''

* <code>-d</code>: Detached mode—run in background
* <code>--name inspector</code>: Give it a memorable name instead of random name

'''Expected output:'''

<pre>Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
Status: Downloaded newer image for nginx:latest
b7f9a8e6c4d3a1b2c5e8f9d2a7c4b6e8f3d9a2c1b4e7f8d3a5c2b1</pre>
The long hex string is the full 64-character container ID. Docker returns this after creating the container.

'''Step 2: Verify the container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b7f9a8e6c4d3 nginx "/docker-entrypoint.…" 10 seconds ago Up 8 seconds 80/tcp inspector</pre>
The container is running nginx web server.

'''Step 3: Get the container's PID on the host'''

Remember: containers are just processes. Let's find the PID:

<syntaxhighlight lang="bash">docker inspect inspector --format '{{.State.Pid}}'</syntaxhighlight>
'''Expected output:''' A number like <code>12345</code>

This is the process ID on the '''host''' system. Let's verify:

<syntaxhighlight lang="bash">ps aux | grep 12345</syntaxhighlight>
You should see nginx processes! The container is just a process with a fancy namespace wrapper.

'''Step 4: Examine the container's namespaces'''

This is the crucial step connecting to Lab 7. Replace 12345 with your actual PID:

<syntaxhighlight lang="bash">sudo ls -la /proc/12345/ns/</syntaxhighlight>
'''Expected output:'''

<pre>total 0
dr-x--x--x 2 root root 0 Dec 12 10:40 .
dr-xr-xr-x 9 root root 0 Dec 12 10:40 ..
lrwxrwxrwx 1 root root 0 Dec 12 10:40 cgroup -> 'cgroup:[4026533671]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 ipc -> 'ipc:[4026533669]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 mnt -> 'mnt:[4026533667]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 net -> 'net:[4026533672]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid -> 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid_for_children -> 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 uts -> 'uts:[4026533668]'</pre>
'''Analysis of namespace inodes:'''

Note the inode numbers (the numbers in brackets). Each represents a namespace instance.

'''Step 5: Compare with host's namespaces'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/net</syntaxhighlight>
'''Expected output:'''

<pre>lrwxrwxrwx 1 youruser youruser 0 Dec 12 10:40 net -> 'net:[4026531992]'</pre>
'''Critical observation:''' The container's network namespace inode (<code>4026533672</code>) is '''different''' from the host's (<code>4026531992</code>).

'''Step 6: Compare two containers'''

Start a second container:

<syntaxhighlight lang="bash">docker run -d --name inspector2 nginx</syntaxhighlight>
Get its PID:

<syntaxhighlight lang="bash">docker inspect inspector2 --format '{{.State.Pid}}'</syntaxhighlight>
Check its network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/NEW_PID/ns/net</syntaxhighlight>
'''Expected:''' A different inode number from both the host and <code>inspector</code> container!

'''Conclusion:''' Each container has its own isolated network namespace, just like the red and blue namespaces you created manually in Lab 7.

'''Step 7: Examine other namespaces'''

Let's check PID namespace isolation:

<syntaxhighlight lang="bash"># Host PID namespace
sudo ls -la /proc/$$/ns/pid

# Container PID namespace
sudo ls -la /proc/CONTAINER_PID/ns/pid</syntaxhighlight>
Different inodes = isolated process trees!

'''Step 8: User namespace (often shared)'''

<syntaxhighlight lang="bash"># Host user namespace
sudo ls -la /proc/$$/ns/user

# Container user namespace
sudo ls -la /proc/CONTAINER_PID/ns/user</syntaxhighlight>
'''Expected:''' Often the '''same''' inode number.

Many Docker configurations share the host's user namespace for simplicity. This means UID 0 in the container is UID 0 on the host (less secure, but more compatible).

For enhanced security, Docker can be configured to use separate user namespaces (rootless Docker), but that's beyond this lab's scope.

'''Step 9: Enter the container's namespace with nsenter'''

You can actually enter a container's namespaces using the <code>nsenter</code> command (this is how <code>docker exec</code> works!):

<syntaxhighlight lang="bash">sudo nsenter --target CONTAINER_PID --net ip addr show</syntaxhighlight>
This executes <code>ip addr show</code> inside the container's network namespace, showing the container's view of network interfaces.

'''Step 10: Clean up'''

<syntaxhighlight lang="bash">docker stop inspector inspector2
docker rm inspector inspector2</syntaxhighlight>

=== Deliverable B ===

Provide screenshots showing:

# Output of <code>docker run hello-world</code> (the full hello message)
# Output of <code>docker ps -a</code> showing the exited hello-world container with its random name
# Output of <code>docker inspect inspector --format '{{.State.Pid}}'</code> (showing the PID)
# Output of <code>sudo ls -la /proc/PID/ns/</code> for the inspector container (showing all namespaces)
# Side-by-side comparison:
#* <code>sudo ls -la /proc/$$/ns/net</code> (host's network namespace inode)
#* <code>sudo ls -la /proc/CONTAINER_PID/ns/net</code> (container's network namespace inode)
#* Highlight that the inode numbers are different


=== Exercise C: Interactive Exploration with Fedora ===

'''Objective:''' Run an interactive container with a different Linux distribution (Fedora instead of Ubuntu), demonstrating mount namespace isolation (different root filesystems), PID namespace isolation (isolated process tree), and UTS namespace isolation (different hostname).

'''Important context:''' Your host might be running Ubuntu, but the container will run Fedora. Both will be using the same Linux kernel, but they'll have completely different filesystems and will appear as different "machines" from inside.

'''Step 1: Run Fedora container interactively'''

<syntaxhighlight lang="bash">docker run -it --name fedora-explore fedora bash</syntaxhighlight>
'''Flags explained:'''

* <code>-i</code>: Interactive—keep STDIN open
* <code>-t</code>: Allocate pseudo-TTY (terminal)
* <code>fedora</code>: Pull Fedora base image from Docker Hub
* <code>bash</code>: Command to run inside container (start bash shell)

'''What happens:'''

# Docker downloads Fedora base image (if not cached)
# Creates container from image
# Starts bash inside the container
# Attaches your terminal to that bash session

'''Expected output:'''

<pre>Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
...
Status: Downloaded newer image for fedora:latest
[root@a1b2c3d4e5f6 /]#</pre>
'''Observe the prompt change:'''

* Before: <code>user@hostname:~$</code> (your normal shell)
* After: <code>[root@a1b2c3d4e5f6 /]#</code> (inside container)

You're now '''inside''' the Fedora container!

'''Step 2: Explore the filesystem (Mount Namespace)'''

Check the operating system:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output:'''

<pre>NAME="Fedora Linux"
VERSION="39 (Container Image)"
ID=fedora
VERSION_ID=39
...</pre>
Open a '''new terminal''' on your host (don't close the container terminal) and run:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output on host:'''

<pre>NAME="Ubuntu"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
ID=ubuntu
...</pre>
'''Two different operating systems on the same machine!''' This is mount namespace isolation—the container has its own root filesystem.

'''Back in the container''', explore the filesystem:

<syntaxhighlight lang="bash">ls /</syntaxhighlight>
'''Expected output:'''

<pre>bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var</pre>
These are Fedora's files, not your host's Ubuntu files. They're completely different directory trees.

'''Try to use Ubuntu's package manager:'''

<syntaxhighlight lang="bash">apt update</syntaxhighlight>
'''Expected output:'''

<pre>bash: apt: command not found</pre>
apt doesn't exist in Fedora! Fedora uses a different package manager.

'''Try Fedora's package manager:'''

<syntaxhighlight lang="bash">dnf --version</syntaxhighlight>
'''Expected output:'''

<pre>4.18.2
Installed: dnf-0:4.18.2-1.fc39.noarch
...</pre>
dnf exists because we're in a Fedora environment.

'''Install a package:'''

<syntaxhighlight lang="bash">dnf install -y nano</syntaxhighlight>
This works! We can install packages just like on a real Fedora system.

'''Connection to Lab 2:'''

In Lab 2, you learned about the filesystem hierarchy (<code>/etc</code>, <code>/var</code>, <code>/usr</code>, etc.). Mount namespaces let the container have completely different contents at these paths. The container's <code>/etc</code> is different from the host's <code>/etc</code>.

'''Step 3: Examine process isolation (PID Namespace)'''

Inside the container, check running processes:

<syntaxhighlight lang="bash">ps aux</syntaxhighlight>
'''Expected output:'''

<pre>USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 12345 2345 pts/0 Ss 10:45 0:00 bash
root 67 0.0 0.0 44567 3456 pts/0 R+ 10:47 0:00 ps aux</pre>
'''Only two processes visible!'''

* PID 1: bash (the container's init process)
* PID 67: ps command we just ran

'''On the host''' (in your other terminal):

<syntaxhighlight lang="bash">ps aux | wc -l</syntaxhighlight>
'''Expected output:''' 200+ processes

'''The container cannot see the host's processes!''' This is PID namespace isolation.

'''From the container's perspective, bash is PID 1''' (like systemd is PID 1 on a normal Linux system).

'''From the host's perspective, that same bash process has a different PID''' (e.g., 12345).

'''Connection to Lab 3:'''

In Lab 3, you learned about PIDs and the process hierarchy. PID namespaces create separate process hierarchies—the container has its own process tree starting from PID 1.

'''Step 4: Check hostname (UTS Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>a1b2c3d4e5f6</pre>
This is the container ID (first 12 characters of the full container ID).

'''On the host:'''

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>your-hostname.example.com</pre>
Different hostnames! This is UTS namespace isolation.

'''Step 5: Examine network configuration (Network Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever

17: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever</pre>
'''Analysis:'''

* <code>lo</code>: Container's loopback interface (127.0.0.1)
* <code>eth0@if18</code>: Container's network interface (part of veth pair)
** <code>@if18</code>: Indicates this interface is paired with interface index 18 (on the host)
** IP address: 172.17.0.2 (from docker0 bridge subnet)

'''On the host:'''

<syntaxhighlight lang="bash">ip addr show | grep "172.17"</syntaxhighlight>
You should see the docker0 bridge has IP 172.17.0.1, and you might see veth interfaces for containers.

'''Connection to Lab 7:'''

This is '''exactly''' what you built manually!

* docker0 bridge ≈ br-lab from Lab 7
* Container's eth0 ≈ v-client from Lab 7
* veth pair connects container to bridge ≈ Lab 7's veth pair architecture

'''Step 6: Test internet connectivity from container'''

<syntaxhighlight lang="bash">ping -c 3 8.8.8.8</syntaxhighlight>
'''Expected:''' Ping succeeds!

This works because:

# Container has default route to 172.17.0.1 (docker0 bridge)
# Host has IP forwarding enabled
# Host has NAT rule (MASQUERADE) for 172.17.0.0/16

'''This is identical to what you configured in Lab 7!'''

'''Step 7: Try to see host's processes (will fail)'''

<syntaxhighlight lang="bash">ps aux | grep systemd</syntaxhighlight>
'''Expected:''' No systemd processes visible.

You cannot see the host's processes from inside the container (PID namespace isolation).

'''Step 8: Exit the container'''

<syntaxhighlight lang="bash">exit</syntaxhighlight>
When you exit bash (PID 1 in the container), the container stops automatically.

'''Verify the container stopped:'''

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
a1b2c3d4e5f6 fedora "bash" 5 minutes ago Exited (0) 10 seconds ago fedora-explore</pre>
'''Note:''' The container still exists (STATUS: Exited), but it's not running. You can restart it with <code>docker start fedora-explore</code> if needed.

'''Step 9: Clean up'''

<syntaxhighlight lang="bash">docker rm fedora-explore</syntaxhighlight>

=== Deliverable C ===

Provide screenshots showing:

# '''Inside container''': Output of <code>cat /etc/os-release</code> (showing Fedora)
# '''On host''': Output of <code>cat /etc/os-release</code> (showing Ubuntu or your host OS)
# '''Inside container''': Output of <code>ps aux</code> (showing minimal processes, bash as PID 1)
# '''On host''': Output of <code>ps aux | wc -l</code> (showing many more processes)
# '''Inside container''': Output of <code>hostname</code> (showing container ID)
# '''On host''': Output of <code>hostname</code> (showing host's hostname)
# '''Inside container''': Output of <code>ip addr show</code> (showing eth0 with 172.17.0.x address)
# Brief explanation (4-5 sentences): What do these differences demonstrate about namespace isolation? How does this relate to what you learned in Labs 2, 3, and 7?


=== Exercise D: Persistent Storage with Caddy ===

'''Objective:''' Run Caddy web server with persistent configuration and content using bind mounts, demonstrating that data can survive container removal and be shared between host and container.

Caddy is the web server you've been using throughout Lab 9. We'll run it in a container and configure it using files from the host.


==== Part 1: Basic Caddy Container ====

'''Step 1: Create directory structure on host'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-caddy/{site,data,config}</syntaxhighlight>
'''Directory purposes:'''

* <code>site</code>: Website content (HTML files)
* <code>data</code>: Caddy's data directory (certificates, storage)
* <code>config</code>: Caddy configuration (Caddyfile)

'''Step 2: Create a simple website'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/site/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Docker Caddy Demo</title>
</head>
<body>
<h1>Hello from Dockerized Caddy!</h1>
<div>
This is running in a Docker container.
The file you're viewing is mounted from the host filesystem.
Changes made on the host appear instantly in the container!
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 3: Create Caddyfile configuration'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/config/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Caddyfile explanation:'''

* <code>:80</code>: Listen on port 80 (inside container)
* <code>root * /usr/share/caddy</code>: Serve files from this directory
* <code>file_server</code>: Enable static file serving
* <code>log</code>: Send access logs to stdout (so <code>docker logs</code> can capture them)

'''Step 4: Run Caddy container with volume mounts'''

<syntaxhighlight lang="bash">docker run -d \
--name caddy-persistent \
-p 8080:80 \
-v ~/lab10-caddy/site:/usr/share/caddy \
-v ~/lab10-caddy/data:/data \
-v ~/lab10-caddy/config:/etc/caddy \
caddy</syntaxhighlight>
'''Breaking down the command:'''

* <code>-d</code>: Detached mode (run in background)
* <code>--name caddy-persistent</code>: Give container a memorable name
* <code>-p 8080:80</code>: Port mapping
** Host port 8080 → Container port 80
** This is NAT (DNAT specifically) from Lab 7!
* <code>-v ~/lab10-caddy/site:/usr/share/caddy</code>: Bind mount
** Host directory <code>~/lab10-caddy/site</code> appears at <code>/usr/share/caddy</code> inside container
** Bidirectional: changes on either side are visible on both sides
* <code>-v ~/lab10-caddy/data:/data</code>: Caddy's data storage
* <code>-v ~/lab10-caddy/config:/etc/caddy</code>: Caddy's configuration
* <code>caddy</code>: Image to use

'''Expected output:'''

<pre>Unable to find image 'caddy:latest' locally
latest: Pulling from library/caddy
...
Status: Downloaded newer image for caddy:latest
f8e9c7b6d5a4e3b2c1f7d8a9e6b5c4d3a2f1e8d7c6b5a4e3d2c1b9f8</pre>
'''Step 5: Verify container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f8e9c7b6d5a4 caddy "caddy run..." 10 seconds ago Up 8 seconds 0.0.0.0:8080->80/tcp caddy-persistent</pre>
'''Note the PORTS column:''' <code>0.0.0.0:8080->80/tcp</code>

This means:

* Listen on all host interfaces (<code>0.0.0.0</code>)
* Host port 8080 maps to container port 80
* Protocol: TCP

'''Step 6: Test the web server'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected output:''' Your HTML page!

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
<head>
<title>Docker Caddy Demo</title>
...
<h1>Hello from Dockerized Caddy!</h1>
...
</html></syntaxhighlight>
You can also open <code>http://localhost:8080</code> in a web browser on your host.

'''Step 7: View Caddy logs'''

<syntaxhighlight lang="bash">docker logs caddy-persistent</syntaxhighlight>
'''Expected output:'''

<pre>{"level":"info","ts":1702389123.456,"msg":"using provided configuration",...}
{"level":"info","ts":1702389123.789,"msg":"serving initial configuration"}
...</pre>
These are Caddy's startup logs. When you access the website, you'll see access logs here too.


==== Part 2: Inspect Mounts ====

'''Step 8: Inspect the container's mounts'''

<syntaxhighlight lang="bash">docker inspect caddy-persistent --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">[
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/site",
"Destination": "/usr/share/caddy",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/data",
"Destination": "/data",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/config",
"Destination": "/etc/caddy",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
]</syntaxhighlight>
'''Field explanations:'''

* <code>Type</code>: "bind" (bind mount, not Docker-managed volume)
* <code>Source</code>: Host filesystem path
* <code>Destination</code>: Path inside container
* <code>RW</code>: true (read-write), false would be read-only
* <code>Propagation</code>: How mount events propagate (rprivate = don't propagate to other mounts)

'''Step 9: View from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent df -h | grep caddy</syntaxhighlight>
Shows mounted filesystems inside the container containing "caddy" in the path.

You can also list the files:

<syntaxhighlight lang="bash">docker exec caddy-persistent ls -la /usr/share/caddy</syntaxhighlight>
'''Expected output:'''

<pre>total 12
drwxr-xr-x 2 root root 4096 Dec 12 10:50 .
drwxr-xr-x 1 root root 4096 Dec 12 10:50 ..
-rw-r--r-- 1 root root 687 Dec 12 10:50 index.html</pre>
This is the same <code>index.html</code> you created on the host!


==== Part 3: Test Persistence ====

'''Step 10: Modify the file on the host'''

'''Without stopping the container''', edit the HTML file:

<syntaxhighlight lang="bash">cat >> ~/lab10-caddy/site/index.html << 'EOF'
<div class="info">
🎉 This was added from the host!
The container is still running, and changes appear instantly.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 11: Verify the change appears in the container immediately'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' The new section appears!

You didn't restart the container, yet the content changed. This demonstrates '''bidirectional bind mount synchronization'''.

'''Step 12: Create a new file from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent /bin/sh -c "echo '<h2>Created from container</h2>' > /usr/share/caddy/test.html"</syntaxhighlight>
'''Step 13: Verify the file appears on the host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected output:'''

<pre>total 16
drwxr-xr-x 2 youruser youruser 4096 Dec 12 11:00 .
drwxr-xr-x 5 youruser youruser 4096 Dec 12 10:45 ..
-rw-r--r-- 1 youruser youruser 687 Dec 12 10:50 index.html
-rw-r--r-- 1 root root 34 Dec 12 11:00 test.html ← New file!</pre>
The file exists on the host! Changes flow both directions.

'''Note:''' The file is owned by <code>root</code> because the process inside the container runs as root. This is one of the complexities of bind mounts—UID/GID mapping between host and container.

'''Step 14: Stop and remove the container'''

<syntaxhighlight lang="bash">docker stop caddy-persistent
docker rm caddy-persistent</syntaxhighlight>
'''Step 15: Verify files still exist on host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected:''' All files still there!

The files survive because they're stored on the host filesystem, not in the container's ephemeral writable layer.

'''Step 16: Start a NEW container with the same bind mounts'''

<syntaxhighlight lang="bash">docker run -d \
--name caddy-new \
-p 8080:80 \
-v ~/lab10-caddy/site:/usr/share/caddy \
-v ~/lab10-caddy/data:/data \
-v ~/lab10-caddy/config:/etc/caddy \
caddy</syntaxhighlight>
'''Step 17: Verify persistence'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' All your previous content is still there!

The website works immediately because all the content and configuration was stored on the host, not inside the old container.

'''Step 18: Compare to ephemeral storage'''

Let's demonstrate what happens without volumes:

<syntaxhighlight lang="bash"># Start container without volumes
docker run -d --name caddy-temp caddy

# Create file inside container
docker exec caddy-temp /bin/sh -c "echo 'temporary' > /tmp/temp.txt"

# Verify file exists
docker exec caddy-temp cat /tmp/temp.txt
# Output: temporary

# Stop and remove container
docker stop caddy-temp
docker rm caddy-temp

# Try to access the file in a new container
docker run -d --name caddy-temp2 caddy
docker exec caddy-temp2 cat /tmp/temp.txt
# Output: cat: /tmp/temp.txt: No such file or directory

# The file is GONE because it was in the ephemeral layer</syntaxhighlight>
'''Step 19: Clean up'''

<syntaxhighlight lang="bash">docker stop caddy-new
docker rm caddy-new</syntaxhighlight>
The files in <code>~/lab10-caddy/</code> remain intact on your host.

<syntaxhighlight lang="bash"># What Docker essentially does:
mount --bind ~/lab10-caddy/site /var/lib/docker/overlay2/.../merged/usr/share/caddy</syntaxhighlight>


=== Deliverable D ===

Provide screenshots showing:

# Output of <code>curl http://localhost:8080</code> showing your custom HTML (initial version)
# Output of <code>docker inspect caddy-persistent --format='{{json .Mounts}}'</code> (formatted with python3 -m json.tool)
# After modifying <code>index.html</code> on the host, output of <code>curl http://localhost:8080</code> showing the new content (without restarting container)
# Output of <code>ls -la ~/lab10-caddy/site/</code> showing both <code>index.html</code> and the <code>test.html</code> created from inside the container
# After removing the original container and starting <code>caddy-new</code>, output of <code>curl http://localhost:8080</code> demonstrating that content persisted


=== Exercise E: Multi-Container Infrastructure with Networking and Resource Limits ===

'''Objective:''' Build a complete three-tier architecture with:

* '''Purple''' container acting as reverse proxy (routes requests based on URL path)
* '''Red''' container serving backend content (memory-limited)
* '''Blue''' container serving backend content (CPU-limited)

This exercise synthesizes everything from Labs 7-9:

* Custom networks (Lab 7 bridges)
* Container-to-container communication (Lab 7 veth pairs and routing)
* Reverse proxy with path-based routing (Lab 9 Caddy configuration)
* Resource limits (cgroups)


==== Part 1: Create a Custom Network ====

'''Step 1: Create a custom bridge network'''

<syntaxhighlight lang="bash">docker network create --subnet=10.10.0.0/24 labnet</syntaxhighlight>
This creates a new bridge (just like <code>br-lab</code> from Lab 7) with subnet 10.10.0.0/24.

'''Expected output:'''

<pre>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2</pre>
This is the network ID.

'''Step 2: Inspect the network'''

<syntaxhighlight lang="bash">docker network inspect labnet</syntaxhighlight>
'''Expected output (abbreviated):'''

<syntaxhighlight lang="json">[
{
"Name": "labnet",
"Id": "a1b2c3d4e5f6...",
"Driver": "bridge",
"IPAM": {
"Config": [
{
"Subnet": "10.10.0.0/24",
"Gateway": "10.10.0.1"
}
]
},
"Containers": {},
...
}
]</syntaxhighlight>
'''Key observations:'''

* <code>Driver: "bridge"</code>: Uses bridge networking (Layer 2 switching)
* <code>Subnet: "10.10.0.0/24"</code>: Our specified subnet
* <code>Gateway: "10.10.0.1"</code>: Docker automatically assigns .1 as gateway
* <code>Containers: {}</code>: No containers connected yet

'''Step 3: Verify bridge creation on host'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
'''Expected output:'''

<pre>5: br-a1b2c3d4e5f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default</pre>
Docker created a new bridge interface! The name includes the network ID prefix.

You can also use:

<syntaxhighlight lang="bash">brctl show</syntaxhighlight>
'''Expected output:'''

<pre>bridge name bridge id STP enabled interfaces
br-a1b2c3d4e5f6 8000.0242a1b2c3d4 no
docker0 8000.0242f7a8b9c0 no</pre>
Two bridges:

* <code>docker0</code>: Default Docker bridge
* <code>br-a1b2c3d4e5f6</code>: Our custom labnet bridge

'''Connection to Lab 7:'''

This is '''exactly''' what you did with:

<syntaxhighlight lang="bash">sudo ip link add br-lab type bridge
sudo ip link set br-lab up
sudo ip addr add 10.0.0.1/24 dev br-lab</syntaxhighlight>
'''Docker automated it!'''


==== Part 2: Create Backend Services (Red and Blue) ====

'''Step 4: Create content directories'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-multicontainer/{red,blue,purple}</syntaxhighlight>
'''Step 5: Create Red service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Red Service</title>
</head>
<body>
<div>
Container: Red
IP: 10.10.0.2
Resource Limit: Memory capped at 256MB
This backend is memory-constrained by cgroups.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 6: Create Red Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Step 7: Create Blue service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Blue Service</title>
</head>
<body>
<h1>Blue Service</h1>
<div class="info">
Container: Blue
IP: 10.10.0.3
Resource Limit: CPU capped at 0.5 cores
This backend is CPU-constrained by cgroups.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 8: Create Blue Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Step 9: Start Red container with memory limit'''

<syntaxhighlight lang="bash">docker run -d \
--name red \
--network labnet \
--ip 10.10.0.2 \
--memory=256m \
--memory-swap=256m \
-v ~/lab10-multicontainer/red:/etc/caddy \
-v ~/lab10-multicontainer/red:/usr/share/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--network labnet</code>: Connect to our custom network (not default docker0)
* <code>--ip 10.10.0.2</code>: Assign static IP address (just like <code>ip addr add</code> in Lab 7!)
* <code>--memory=256m</code>: cgroup memory limit (hard cap: 256MB RAM)
* <code>--memory-swap=256m</code>: Total memory+swap limit (setting equal to memory means no swap)
** If swap was 512m, container could use 256MB RAM + 256MB swap
* <code>-v ~/lab10-multicontainer/red:/etc/caddy</code>: Mount Caddyfile
* <code>-v ~/lab10-multicontainer/red:/usr/share/caddy</code>: Mount website content

'''Expected output:''' Container ID

'''Step 10: Verify Red is running'''

<syntaxhighlight lang="bash">docker ps --filter "name=red"</syntaxhighlight>
'''Step 11: Test Red directly'''

Since Red has IP 10.10.0.2, let's verify we can reach it:

<syntaxhighlight lang="bash"># From host (won't work directly because we're not in labnet)
# But we can use docker exec from another container

# Quick test: use docker exec to reach Red from Red itself
docker exec red curl -s http://localhost | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Red Service</h1></pre>
'''Step 12: Start Blue container with CPU limit'''

<syntaxhighlight lang="bash">docker run -d \
--name blue \
--network labnet \
--ip 10.10.0.3 \
--cpus=0.5 \
-v ~/lab10-multicontainer/blue:/etc/caddy \
-v ~/lab10-multicontainer/blue:/usr/share/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--cpus=0.5</code>: cgroup CPU limit (maximum 50% of one CPU core)
** If CPU-intensive work is attempted, kernel will throttle it
* Other flags same as Red

'''Step 13: Verify both containers are running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 caddy "caddy run..." 20 seconds ago Up 18 seconds 80/tcp red
b7c8d9e0f1a2 caddy "caddy run..." 10 seconds ago Up 8 seconds 80/tcp blue</pre>
'''Step 14: Test container-to-container communication'''

<syntaxhighlight lang="bash"># From Red, ping Blue
docker exec red ping -c 2 10.10.0.3</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># From Red, curl Blue's website
docker exec red curl -s http://10.10.0.3 | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Blue Service</h1></pre>
Containers on the same custom network can communicate directly.


==== Part 3: Create Reverse Proxy (Purple) ====

'''Step 15: Create Purple's Caddyfile'''

This is the crucial piece—routing based on URL path (from Lab 9!)

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/purple/Caddyfile << 'EOF'
:80 {
# Health check endpoint
handle /health {
respond "Purple Reverse Proxy - OK" 200
}

# Root path
handle / {
respond "Purple Reverse Proxy - Use /red/ or /blue/ paths" 200
}

# Route /red/* to red container (strip /red prefix)
handle_path /red/* {
reverse_proxy red:80
}

# Route /blue/* to blue container (strip /blue prefix)
handle_path /blue/* {
reverse_proxy blue:80
}

# Logging
log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Key points:'''

* <code>handle_path /red/*</code>: Matches any path starting with <code>/red/</code>
** <code>handle_path</code> strips the prefix before forwarding
** Client requests <code>/red/index.html</code> → Backend receives <code>/index.html</code>
* <code>reverse_proxy red:80</code>: Forward to container named "red" on port 80
** '''Using hostname "red", not IP!'''
** Docker's embedded DNS resolves "red" to 10.10.0.2
* Same for blue

'''Step 16: Start Purple reverse proxy'''

<syntaxhighlight lang="bash">docker run -d \
--name purple \
--network labnet \
--ip 10.10.0.10 \
-p 8080:80 \
-v ~/lab10-multicontainer/purple:/etc/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--ip 10.10.0.10</code>: Purple gets IP 10.10.0.10 (different from Red/Blue)
* <code>-p 8080:80</code>: '''Port mapping''' (host port 8080 → container port 80)
** This is NAT (DNAT) from Lab 7!
** Traffic to <code>localhost:8080</code> on host gets forwarded to <code>10.10.0.10:80</code> in container


==== Part 4: Testing the Infrastructure ====

'''Step 17: Test health check'''

<syntaxhighlight lang="bash">curl http://localhost:8080/health</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - OK</pre>
This request:

# Reaches host's port 8080
# Docker's DNAT rule forwards to Purple (10.10.0.10:80)
# Purple's Caddy responds directly (no backend needed for /health)

'''Step 18: Test root path'''

<syntaxhighlight lang="bash">curl http://localhost:8080/</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - Use /red/ or /blue/ paths</pre>
'''Step 19: Test routing to Red'''

<syntaxhighlight lang="bash">curl http://localhost:8080/red/</syntaxhighlight>
'''Expected output:''' Red service HTML (with red background styling)

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
...
<h1>Red Service</h1>
<div>
Container: Red
IP: 10.10.0.2
...</syntaxhighlight>
'''What happened:'''

# Your curl → Host port 8080
# DNAT → Purple (10.10.0.10:80)
# Purple sees path <code>/red/</code>, strips <code>/red</code>, forwards <code>/</code> to <code>red:80</code>
# Purple's DNS resolves <code>red</code> to 10.10.0.2
# Request goes to Red (10.10.0.2:80)
# Red's Caddy serves <code>index.html</code>
# Response travels back through Purple to your curl

'''Step 20: Test routing to Blue'''

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/</syntaxhighlight>
'''Expected output:''' Blue service HTML (with blue background styling)

'''Step 21: Test with verbose output to see headers'''

<syntaxhighlight lang="bash">curl -v http://localhost:8080/red/ 2>&1 | grep -A10 "< HTTP"</syntaxhighlight>
'''Expected output:'''

<pre>< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Server: Caddy
< Date: Thu, 12 Dec 2024 11:30:00 GMT
< Content-Length: 687</pre>
'''Observe:''' <code>Server: Caddy</code> header (from Purple, acting as proxy)

'''Step 22: Test in browser'''

Open in your web browser:

* <code>http://localhost:8080/red/</code> → Should see red-styled page
* <code>http://localhost:8080/blue/</code> → Should see blue-styled page


==== Part 5: Inspect Resource Limits ====

'''Step 23: Check Red's memory limit'''

<syntaxhighlight lang="bash">docker inspect red --format='{{.HostConfig.Memory}}'</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
This is 256 MB in bytes (256 × 1024 × 1024 = 268435456).

'''Step 24: Check Blue's CPU limit'''

<syntaxhighlight lang="bash">docker inspect blue --format='{{.HostConfig.NanoCpus}}'</syntaxhighlight>
'''Expected output:'''

<pre>500000000</pre>
This is 0.5 CPU cores in nanocpus (0.5 × 10^9 = 500,000,000).

'''Step 25: View cgroup settings from the host'''

Get Red's main process PID:

<syntaxhighlight lang="bash">RED_PID=$(docker inspect red --format '{{.State.Pid}}')
echo "Red's PID: $RED_PID"</syntaxhighlight>
View memory limit in cgroup filesystem:

<syntaxhighlight lang="bash">cat /sys/fs/cgroup/memory/docker/$RED_PID/memory.limit_in_bytes</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
View Blue's CPU quota:

<syntaxhighlight lang="bash">BLUE_PID=$(docker inspect blue --format '{{.State.Pid}}')
cat /sys/fs/cgroup/cpu/docker/$BLUE_PID/cpu.cfs_quota_us</syntaxhighlight>
'''Expected output:'''

<pre>50000</pre>
'''Explanation:'''

* <code>cpu.cfs_period_us</code>: 100000 (default, 100ms period)
* <code>cpu.cfs_quota_us</code>: 50000 (50ms out of 100ms = 50% = 0.5 CPUs)

'''Connection to kernel concepts:'''

These cgroup files in <code>/sys/fs/cgroup/</code> are how the kernel enforces resource limits. Docker configures these files, and the kernel does the actual enforcement.


==== Part 6: Network Inspection ====

'''Step 26: Inspect labnet network showing all containers'''

<syntaxhighlight lang="bash">docker network inspect labnet --format='{{json .Containers}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">{
"a1b2c3d4e5f6...": {
"Name": "red",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:02",
"IPv4Address": "10.10.0.2/24",
"IPv6Address": ""
},
"b7c8d9e0f1a2...": {
"Name": "blue",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:03",
"IPv4Address": "10.10.0.3/24",
"IPv6Address": ""
},
"f8e9c7b6d5a4...": {
"Name": "purple",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:0a",
"IPv4Address": "10.10.0.10/24",
"IPv6Address": ""
}
}</syntaxhighlight>
All three containers are on the labnet network with their assigned IPs.

'''Step 27: Test DNS resolution between containers'''

<syntaxhighlight lang="bash"># From Purple, resolve "red" hostname
docker exec purple nslookup red</syntaxhighlight>
'''Expected output:'''

<pre>Server: 127.0.0.11
Address: 127.0.0.11#53

Non-authoritative answer:
Name: red
Address: 10.10.0.2</pre>
'''Explanation:'''

* <code>127.0.0.11</code>: Docker's embedded DNS server (listening inside each container)
* DNS resolves container name "red" to IP 10.10.0.2

'''Step 28: Test connectivity using hostnames'''

<syntaxhighlight lang="bash"># Purple pings Red by hostname
docker exec purple ping -c 2 red</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># Purple curls Blue by hostname
docker exec purple curl -s http://blue | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Blue Service</h1></pre>

==== Part 7: Architecture Visualization ====

'''The architecture you built:'''

<pre> ┌─────────────────┐
│ Your Host │
│ (Port 8080) │
└────────┬────────┘
│
Port Mapping (NAT)
8080 → 80
│
┌────────▼────────┐
│ Purple Proxy │
│ 10.10.0.10:80 │
│ (Caddy) │
└────────┬────────┘
│
Docker Network: labnet
(Bridge: br-a1b2c3d4e5f6)
10.10.0.0/24
│
┌─────────┴──────────┐
│ │
┌────────▼────────┐ ┌───────▼─────────┐
│ Red Service │ │ Blue Service │
│ 10.10.0.2:80 │ │ 10.10.0.3:80 │
│ (Caddy) │ │ (Caddy) │
│ [mem: 256MB] │ │ [cpu: 0.5] │
└─────────────────┘ └─────────────────┘</pre>
'''Request flow for <code>curl http://localhost:8080/red/</code>:'''

<pre>1. Curl → localhost:8080 (your host)
2. Host's iptables DNAT rule → 10.10.0.10:80 (Purple)
3. Purple receives request to /red/
4. Purple's Caddy config: handle_path /red/* → reverse_proxy red:80
5. Purple strips /red prefix → request becomes /
6. Purple's DNS resolves "red" → 10.10.0.2
7. Purple → Red (10.10.0.2:80) GET /
8. Red's Caddy serves /usr/share/caddy/index.html
9. Response: Red → Purple → Host → Curl</pre>
'''Compare to Lab 7 and Lab 9:'''

* '''Lab 7''': You manually created bridges, veth pairs, assigned IPs, configured routes, set up NAT
* '''Lab 9''': You manually configured Caddy reverse proxy with path-based routing
* '''This exercise''': Docker automated all the networking, you just specified what you wanted


==== Part 8: Cleanup ====

'''Step 29: Stop all containers'''

<syntaxhighlight lang="bash">docker stop purple red blue</syntaxhighlight>
'''Step 30: Remove containers'''

<syntaxhighlight lang="bash">docker rm purple red blue</syntaxhighlight>
'''Step 31: Remove the network'''

<syntaxhighlight lang="bash">docker network rm labnet</syntaxhighlight>
'''Step 32: Verify cleanup'''

<syntaxhighlight lang="bash">docker ps -a
docker network ls</syntaxhighlight>
Only default networks (bridge, host, none) should remain.

'''Step 33: Verify host bridge removed'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
The custom bridge (br-a1b2c3d4e5f6) should be gone. Only docker0 remains.


=== Deliverable E ===

Provide screenshots showing:

# Output of <code>docker network inspect labnet</code> showing all three containers with their IPs (before running curl tests)
# Output of <code>curl http://localhost:8080/health</code> (health check response)
# Output of <code>curl http://localhost:8080/red/</code> (Red service HTML) with visible red-styled content
# Output of <code>curl http://localhost:8080/blue/</code> (Blue service HTML) with visible blue-styled content
# Output of <code>docker inspect red --format='{{.HostConfig.Memory}}'</code> showing memory limit in bytes
# Output of <code>docker inspect blue --format='{{.HostConfig.NanoCpus}}'</code> showing CPU limit in nanocpus
# Output of <code>docker exec purple nslookup red</code> showing DNS resolution


== Reference: Docker Command Quick Guide ==

This section provides a quick reference for Docker commands introduced in this lab.


=== Container Lifecycle ===

<syntaxhighlight lang="bash"># Run container (create + start)
docker run [OPTIONS] IMAGE [COMMAND]
docker run -d nginx # Detached (background)
docker run -it ubuntu bash # Interactive with terminal
docker run --name mycontainer nginx # Assign name

# List containers
docker ps # Running only
docker ps -a # All (including stopped)
docker ps -q # Show only IDs (quiet)

# Start stopped container
docker start CONTAINER

# Stop running container
docker stop CONTAINER # Graceful (SIGTERM)
docker kill CONTAINER # Forceful (SIGKILL)

# Restart container
docker restart CONTAINER

# Remove container
docker rm CONTAINER # Must be stopped first
docker rm -f CONTAINER # Force remove (stop + remove)

# Execute command in running container
docker exec CONTAINER COMMAND
docker exec -it CONTAINER bash # Interactive shell

# View container logs
docker logs CONTAINER
docker logs -f CONTAINER # Follow (tail -f style)

# Inspect container (detailed JSON info)
docker inspect CONTAINER
docker inspect CONTAINER --format='{{.State.Status}}'</syntaxhighlight>

=== Image Management ===

<syntaxhighlight lang="bash"># List images
docker images
docker image ls

# Pull image from registry
docker pull IMAGE[:TAG]
docker pull nginx # Latest tag (default)
docker pull nginx:1.21 # Specific tag

# Remove image
docker rmi IMAGE
docker image rm IMAGE

# View image layers
docker history IMAGE

# Remove unused images
docker image prune # Dangling images
docker image prune -a # All unused images</syntaxhighlight>

=== Network Management ===

<syntaxhighlight lang="bash"># List networks
docker network ls

# Create network
docker network create NETWORK
docker network create --subnet=10.20.0.0/24 mynet

# Inspect network
docker network inspect NETWORK

# Connect container to network
docker network connect NETWORK CONTAINER

# Disconnect container from network
docker network disconnect NETWORK CONTAINER

# Remove network
docker network rm NETWORK

# Remove unused networks
docker network prune</syntaxhighlight>

=== Volume Management ===

<syntaxhighlight lang="bash"># List volumes
docker volume ls

# Create volume
docker volume create VOLUME

# Inspect volume
docker volume inspect VOLUME

# Remove volume
docker volume rm VOLUME

# Remove unused volumes
docker volume prune</syntaxhighlight>

=== Resource Management ===

<syntaxhighlight lang="bash"># CPU limits
--cpus=1.5 # Limit to 1.5 CPU cores
--cpu-shares=512 # Relative priority (default 1024)
--cpuset-cpus=0,1 # Pin to specific cores

# Memory limits
--memory=512m # Hard limit: 512 MB RAM
--memory=2g # Hard limit: 2 GB RAM
--memory-swap=1g # Total memory+swap
--memory-reservation=256m # Soft limit

# I/O limits
--device-read-bps=/dev/sda:10mb # Limit read bandwidth
--device-write-bps=/dev/sda:10mb # Limit write bandwidth

# Process limits
--pids-limit=100 # Max 100 processes</syntaxhighlight>

=== Inspection and Debugging ===

<syntaxhighlight lang="bash"># View resource usage stats
docker stats
docker stats CONTAINER # Specific container

# View processes in container
docker top CONTAINER

# View port mappings
docker port CONTAINER

# Copy files between host and container
docker cp CONTAINER:/path/to/file ./file # Container → Host
docker cp ./file CONTAINER:/path/to/file # Host → Container

# Stream events from Docker daemon
docker events

# Show disk usage
docker system df

# System-wide cleanup
docker system prune # Remove unused objects
docker system prune -a # Remove all unused objects
docker system prune -a --volumes # Include volumes</syntaxhighlight>

== Common Troubleshooting ==


=== Installation Issues ===

'''Problem:''' <code>docker --version</code> fails after installation

'''Solution:'''

<syntaxhighlight lang="bash"># Check if Docker daemon is running
sudo systemctl status docker

# If not running, start it
sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
'''Problem:''' "Cannot connect to the Docker daemon"

'''Cause:''' Docker daemon not running or permission issue

'''Solution:'''

<syntaxhighlight lang="bash"># Check daemon status
sudo systemctl status docker

# Check if your user is in docker group
groups | grep docker

# If not, add user and log out/in
sudo usermod -aG docker $USER</syntaxhighlight>

=== Permission Issues ===

'''Problem:''' "permission denied" when running docker commands

'''Solution:'''

<syntaxhighlight lang="bash"># Option 1: Add user to docker group (permanent)
sudo usermod -aG docker $USER
# Then log out and log back in

# Option 2: Use sudo (temporary)
sudo docker run hello-world</syntaxhighlight>
'''Problem:''' Files created by container are owned by root

'''Cause:''' Container runs as root (UID 0) by default

'''Solution:'''

<syntaxhighlight lang="bash"># Run container as specific user
docker run --user $(id -u):$(id -g) IMAGE

# Or use user namespaces (advanced)</syntaxhighlight>

=== Network Issues ===

'''Problem:''' Container can't access internet

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Test from container
docker exec CONTAINER ping -c 2 8.8.8.8

# Check Docker's NAT rules
sudo iptables -t nat -L -n | grep docker

# Check IP forwarding
sysctl net.ipv4.ip_forward</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Enable IP forwarding if disabled
sudo sysctl -w net.ipv4.ip_forward=1

# Restart Docker daemon
sudo systemctl restart docker</syntaxhighlight>
'''Problem:''' Containers on custom network can't communicate

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check network exists
docker network ls

# Check containers are on same network
docker network inspect NETWORK

# Test connectivity
docker exec CONTAINER1 ping CONTAINER2_IP</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Ensure both containers on same network
docker network connect NETWORK CONTAINER</syntaxhighlight>
'''Problem:''' Port mapping not working (<code>-p</code> flag)

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check port is actually mapped
docker port CONTAINER

# Check if host port is already in use
sudo ss -tulpn | grep :8080</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># If port in use, use different host port
docker run -p 8081:80 nginx

# Or stop the conflicting process
sudo fuser -k 8080/tcp</syntaxhighlight>

=== Storage Issues ===

'''Problem:''' "No space left on device"

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check Docker disk usage
docker system df

# Check host disk space
df -h /var/lib/docker</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Remove unused objects
docker system prune -a

# Remove specific old images
docker images
docker rmi IMAGE_ID</syntaxhighlight>
'''Problem:''' Changes in bind mount not visible in container

'''Cause:''' Path doesn't exist or wrong path specified

'''Solution:'''

<syntaxhighlight lang="bash"># Verify path exists on host
ls -la /path/to/host/directory

# Use absolute paths
docker run -v /absolute/path:/container/path IMAGE

# Or use $PWD for current directory
docker run -v $PWD/relative/path:/container/path IMAGE</syntaxhighlight>

=== Resource Limit Issues ===

'''Problem:''' Container killed unexpectedly

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check container exit code
docker inspect CONTAINER --format='{{.State.ExitCode}}'
# Exit code 137 = killed (often OOM)

# Check logs
docker logs CONTAINER</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Increase memory limit
docker run --memory=1g IMAGE

# Or run without memory limit (default)
docker run IMAGE</syntaxhighlight>
'''Problem:''' Container using too much CPU

'''Solution:'''

<syntaxhighlight lang="bash"># Limit CPU usage
docker run --cpus=0.5 IMAGE

# Check what's consuming CPU
docker exec CONTAINER top</syntaxhighlight>

== Next Steps: Dockerfile and Docker Compose ==

Congratulations! You've mastered the fundamental OS concepts behind containers:

* '''Namespaces''' provide isolation (network, PID, mount, UTS, IPC, user, cgroup)
* '''cgroups''' enforce resource limits (CPU, memory, I/O)
* '''OverlayFS''' provides efficient layered filesystems
* '''Bridges and veth pairs''' connect containers (same as Lab 7!)
* '''Volumes''' persist data beyond container lifecycles

However, you've been using '''pre-built images''' and running containers with long <code>docker run</code> commands. In production environments, you need:

# '''Custom images''' tailored to your applications
# '''Reproducible builds''' that can be version-controlled
# '''Multi-container orchestration''' with coordinated startup and networking

This is where '''Dockerfile''' and '''Docker Compose''' come in.


=== Dockerfile: Building Custom Images ===

Instead of starting from a base image and manually installing packages, you define your application's environment in a <code>Dockerfile</code>:

<syntaxhighlight lang="dockerfile"># Start from Ubuntu base image
FROM ubuntu:22.04

# Install dependencies
RUN apt-get update && apt-get install -y \
python3 \
python3-pip \
&& rm -rf /var/lib/apt/lists/*

# Copy application code
COPY app.py /app/
COPY requirements.txt /app/

# Install Python dependencies
WORKDIR /app
RUN pip3 install -r requirements.txt

# Expose port
EXPOSE 8000

# Define startup command
CMD ["python3", "app.py"]</syntaxhighlight>
'''Build the image:'''

<syntaxhighlight lang="bash">docker build -t myapp:1.0 .</syntaxhighlight>
'''Run containers from your custom image:'''

<syntaxhighlight lang="bash">docker run -d -p 8000:8000 myapp:1.0</syntaxhighlight>
'''Benefits:'''

* '''Reproducibility''': Same Dockerfile always builds identical image
* '''Version control''': Dockerfile lives in git alongside code
* '''Documentation''': Dockerfile explicitly documents dependencies and setup
* '''Automation''': CI/CD pipelines can build images automatically

'''Common Dockerfile instructions:'''

* <code>FROM</code>: Base image to start from
* <code>RUN</code>: Execute command during build (install packages, etc.)
* <code>COPY</code> / <code>ADD</code>: Copy files from host into image
* <code>WORKDIR</code>: Set working directory
* <code>ENV</code>: Set environment variables
* <code>EXPOSE</code>: Document which ports the application uses
* <code>CMD</code>: Default command to run when container starts
* <code>ENTRYPOINT</code>: Configure container as executable

'''Best practices:'''

* Use specific image tags (not <code>latest</code>)
* Minimize layers (combine <code>RUN</code> commands)
* Leverage build cache (order instructions from least to most frequently changing)
* Use <code>.dockerignore</code> (like <code>.gitignore</code> for Docker builds)
* Don't run as root (use <code>USER</code> instruction)
* Multi-stage builds for smaller images


=== Docker Compose: Multi-Container Orchestration ===

Instead of running multiple <code>docker run</code> commands with complex options, define your entire infrastructure in a <code>docker-compose.yml</code> file:

<syntaxhighlight lang="yaml">version: '3.8'

services:
# Purple reverse proxy
purple:
image: caddy
ports:
- "8080:80"
volumes:
- ./purple:/etc/caddy
networks:
labnet:
ipv4_address: 10.10.0.10
depends_on:
- red
- blue

# Red backend
red:
image: caddy
volumes:
- ./red:/etc/caddy
- ./red:/usr/share/caddy
networks:
labnet:
ipv4_address: 10.10.0.2
deploy:
resources:
limits:
memory: 256M

# Blue backend
blue:
image: caddy
volumes:
- ./blue:/etc/caddy
- ./blue:/usr/share/caddy
networks:
labnet:
ipv4_address: 10.10.0.3
deploy:
resources:
limits:
cpus: '0.5'

networks:
labnet:
driver: bridge
ipam:
config:
- subnet: 10.10.0.0/24</syntaxhighlight>
'''Start entire infrastructure:'''

<syntaxhighlight lang="bash">docker compose up</syntaxhighlight>
Or in detached mode:

<syntaxhighlight lang="bash">docker compose up -d</syntaxhighlight>
'''Stop everything:'''

<syntaxhighlight lang="bash">docker compose down</syntaxhighlight>
'''View logs:'''

<syntaxhighlight lang="bash">docker compose logs -f</syntaxhighlight>
'''Benefits:'''

* '''Declarative''': Describe desired state, not imperative commands
* '''Single source of truth''': One file defines entire application
* '''Easy to share''': Colleagues can run <code>docker compose up</code> and get identical environment
* '''Development/production parity''': Same compose file works everywhere
* '''Automatic networking''': Compose creates network and DNS automatically

'''This is the production-ready way to deploy multi-container applications.'''

'''Further learning:'''

* '''Dockerfile''': Learn advanced instructions, multi-stage builds, build arguments
* '''Docker Compose''': Learn service dependencies, health checks, scaling
* '''Docker Swarm''': Docker's built-in orchestration for multi-host deployments
* '''Kubernetes''': Industry-standard container orchestration platform
* '''Container registries''': Push images to Docker Hub, GitHub Container Registry, or private registries
* '''Security''': Image scanning, rootless Docker, seccomp profiles, AppArmor

These topics build on the solid foundation you've established in this lab. You now understand what containers actually are at the OS level—the rest is learning tools that make containers easier to build and deploy.


== Deliverables and Assessment ==

Submit a single PDF document containing all deliverables from Exercises A through E, organized with clear section headers matching the exercise labels.

'''Required deliverables:'''

* '''Deliverable A''': Installation verification (screenshots)
* '''Deliverable B''': Hello World and namespace inspection (screenshots)
* '''Deliverable C''': Fedora exploration (screenshots)
* '''Deliverable D''': Persistent storage (screenshots)
* '''Deliverable E''': Multi-container infrastructure (screenshots)


== Additional Resources ==

This lab introduced containerization using Docker, demonstrating how Linux kernel features (namespaces, cgroups, OverlayFS) are composed to create isolated application environments. You've seen that Docker is not magic—it's sophisticated automation of kernel primitives you already understand from previous labs.


=== For Further Study ===

'''Container Internals:'''

* Deep dive into runc (the OCI runtime that Docker uses)
* Understanding containerd (container runtime layer)
* Linux capabilities and security contexts
* AppArmor and SELinux profiles for containers
* User namespaces and rootless containers
* Seccomp profiles for system call filtering

'''Dockerfile Best Practices:'''

* Multi-stage builds for smaller images
* Build cache optimization strategies
* Layer ordering for efficient rebuilds
* .dockerignore for excluding files
* Security scanning with Trivy or Clair
* Distroless and minimal base images

'''Docker Compose Advanced:'''

* Service dependencies with health checks
* Environment-specific overrides
* Secrets management
* Multiple compose files (base + overrides)
* Named volumes vs bind mounts
* Integration testing with compose

'''Container Orchestration:'''

* Kubernetes architecture and concepts
* kubectl basics
* Pods, Services, Deployments, ConfigMaps
* Kubernetes networking (CNI plugins)
* Helm charts for package management
* Service mesh (Istio, Linkerd)

'''Container Networking Deep Dive:'''

* Bridge vs host vs macvlan networking
* Overlay networks for multi-host communication
* Network plugins and CNI specification
* Load balancing strategies
* Service discovery patterns
* Network policies and segmentation

'''Security:'''

* Container escape techniques and mitigations
* Image vulnerability scanning
* Runtime security monitoring (Falco)
* Least privilege principles
* Supply chain security
* Harbor for secure image registry

'''Performance:'''

* Container resource tuning
* Storage drivers (overlay2, btrfs, zfs)
* Network performance optimization
* Monitoring with Prometheus and Grafana
* Distributed tracing with Jaeger

'''Production Operations:'''

* Logging strategies (centralized logging)
* Health checks and readiness probes
* Rolling updates and blue-green deployments
* Backup and disaster recovery
* CI/CD integration (Jenkins, GitLab CI)
* Container registries (private, public)


=== Relevant Manual Pages ===

<syntaxhighlight lang="bash">man 7 namespaces # Linux namespaces overview
man 7 cgroups # Control groups overview
man 2 unshare # Create namespaces
man 2 setns # Enter existing namespace
man 8 nsenter # Run program in namespace
man 1 docker # Docker CLI reference
man 1 docker-run # docker run reference
man 1 docker-compose # Docker Compose reference</syntaxhighlight>

=== Online Resources ===

'''Official Documentation:'''

* [https://docs.docker.com/ Docker Documentation] - Comprehensive official docs
* [https://hub.docker.com/ Docker Hub] - Public image registry
* [https://opencontainers.org/ OCI Specification] - Open Container Initiative standards
* [https://containerd.io/docs/ containerd Documentation] - Container runtime

'''Tutorials and Guides:'''

* [https://docker-curriculum.com/ Docker Curriculum] - Beginner-friendly tutorial
* [https://labs.play-with-docker.com/ Play with Docker] - Free interactive playground
* [https://kubernetes.io/docs/ Kubernetes Documentation] - K8s official docs
* [https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ Dockerfile Best Practices]

'''Deep Dives:'''

* [https://lwn.net/Articles/531114/ Understanding Namespaces (LWN)] - Series on Linux namespaces
* [https://jvns.ca/blog/2016/10/10/what-even-is-a-container/ How Containers Work] - Excellent blog post by Julia Evans
* [https://sysdig.com/blog/dockerfile-best-practices/ Container Security Best Practices] - Security-focused guide

'''Community:'''

* [https://forums.docker.com/ Docker Forums] - Community support
* [https://stackoverflow.com/questions/tagged/docker Stack Overflow - Docker Tag]
* [https://reddit.com/r/docker Reddit r/docker]
* [https://slack.cncf.io/ CNCF Slack] - Cloud Native Computing Foundation community

'''Practice Environments:'''

* [https://www.katacoda.com/ Katacoda] - Interactive Docker and Kubernetes scenarios
* [https://labs.play-with-k8s.com/ Play with Kubernetes] - K8s playground
* [https://killercoda.com/ KillerCoda] - Interactive learning scenarios

OS Lab 10 - Containers and Docker

2025-12-16T16:05:50Z

Vserbu: /* Exercise A: Installing Docker */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how containers use Linux kernel namespaces (PID, mount, network, UTS, IPC, user, cgroup) to provide process isolation without requiring separate operating systems or hypervisors.
* Differentiate between container images (immutable filesystem templates) and running containers (ephemeral process instances in isolated namespaces).
* Understand how OverlayFS provides efficient layered filesystems that allow multiple containers to share common base layers while maintaining separate writable layers.
* Apply cgroup resource limits to constrain container CPU, memory, and I/O usage, preventing resource monopolization.
* Configure Docker networking using custom bridges, port mapping (NAT), and container-to-container communication with automatic DNS resolution.
* Use volumes and bind mounts to persist data beyond container lifecycles and share data between containers and the host.
* Build multi-container applications with coordinated networking and resource management, demonstrating modern microservices architecture patterns.
* Connect container concepts to previous labs: relate network namespaces to Lab 7, mount namespaces to Lab 2, PID namespaces to Lab 3, and Docker networking to Labs 7-9.


== Introduction ==


=== From Manual Isolation to Automated Containers ===

In Labs 7-9, you manually constructed network isolation using Linux kernel primitives. You created virtual network interfaces with <code>ip link add type veth</code>, configured bridges with <code>ip link add type bridge</code>, established isolated network stacks with <code>ip netns add</code>, and set up routing and NAT rules. Through this hands-on work, you gained deep insight into how the Linux kernel provides network isolation at the namespace level.

Every time you executed <code>sudo ip netns exec red ping 10.0.0.3</code>, you were demonstrating a fundamental concept: the kernel can create completely isolated environments where processes see only a subset of system resources. The <code>red</code> namespace had its own network interfaces, its own routing table, and its own firewall rules—completely invisible to processes running in other namespaces or on the host.

This isolation is powerful, but network namespaces are just one of seven namespace types that the Linux kernel provides. To fully isolate an application and create what we call a "container," you need:

* '''Network namespace''' (<code>net</code>): Isolated network stack—you've mastered this in Labs 7-9
* '''PID namespace''' (<code>pid</code>): Isolated process tree—each namespace has its own PID 1
* '''Mount namespace''' (<code>mnt</code>): Isolated filesystem view—different root directory from the host
* '''UTS namespace''' (<code>uts</code>): Isolated hostname—each container can have its own hostname
* '''IPC namespace''' (<code>ipc</code>): Isolated inter-process communication—shared memory, semaphores, message queues
* '''User namespace''' (<code>user</code>): Isolated UIDs/GIDs—security boundary for privilege separation
* '''Cgroup namespace''' (<code>cgroup</code>): Isolated view of control group hierarchy

Additionally, you need:

* '''Control groups (cgroups)''' to limit CPU, memory, and I/O resources
* '''Copy-on-write filesystems''' (OverlayFS) for efficient storage
* '''Image management''' for distributing application packages
* '''Orchestration''' for managing the lifecycle of multiple isolated environments

Manually setting up all of these components for every application would require hundreds of commands and deep kernel knowledge. This is the problem that containerization technology solves.


=== What are Containers? ===

A '''container''' is an isolated process (or process tree) that uses Linux kernel features—namespaces, cgroups, and layered filesystems—to provide the illusion of running in a separate system. Containers package an application with its dependencies, libraries, and configuration into a single unit that can run consistently across different environments.

Containers are not a specific product or tool—they are a pattern for using kernel isolation features. Multiple container runtimes exist, each implementing this pattern:

'''Container Runtimes:'''

* '''Docker''': The most widely adopted container platform, providing a complete ecosystem (daemon, CLI, image format, registry)
* '''Podman''': Daemonless container engine, compatible with Docker images and commands, can run rootless
* '''containerd''': Industry-standard container runtime, used by Kubernetes and Docker (as of Docker 1.11+)
* '''CRI-O''': Lightweight container runtime built for Kubernetes, implementing the Container Runtime Interface (CRI)
* '''LXC/LXD''': System containers that more closely resemble traditional VMs, providing full init systems

'''What Container Runtimes Provide:'''

# '''Namespace Management''': Automatically create and configure all necessary namespace types
# '''Filesystem Layers''': Use OverlayFS or similar copy-on-write filesystems for efficient storage
# '''Network Configuration''': Set up bridges, veth pairs, and NAT rules automatically
# '''Resource Control''': Configure cgroups to enforce CPU and memory limits
# '''Image Distribution''': Provide standard formats (OCI) for packaging and distributing applications
# '''Lifecycle Management''': Offer commands to create, start, stop, and remove containers


=== Docker as a Container Runtime ===

In this lab, we use '''Docker''' because it is the most widely deployed and well-documented container runtime. Docker's architecture consists of:

* '''Docker Engine (dockerd)''': Daemon that manages containers
* '''Docker CLI (docker)''': Command-line interface for interacting with the daemon
* '''containerd''': Lower-level runtime that Docker uses internally
* '''runc''': OCI-compliant runtime that actually creates and runs containers

When you execute <code>docker run nginx</code>, Docker performs approximately 50-100 system calls to configure namespaces, mount filesystems, set up networking, and start the process—all operations you could do manually but would require significant time and expertise.

The concepts you learn with Docker apply to all container runtimes, as they all use the same underlying kernel features. The commands may differ (e.g., <code>podman run</code> instead of <code>docker run</code>), but the fundamental mechanisms remain the same.


=== The Shift in Software Deployment ===

Containers represent a fundamental paradigm shift in how we think about software deployment and infrastructure management.

'''Traditional Deployment Model (Pre-Container Era):'''

<pre>1. Provision a server (physical or virtual machine)
2. Install operating system (Ubuntu, RHEL, etc.)
3. Install runtime dependencies (Python 3.9, Node.js 16, specific library versions)
4. Configure environment variables, users, permissions
5. Deploy application code
6. Configure monitoring, logging, security
7. Hope everything works the same as on your development machine
8. Troubleshoot when it doesn't ("works on my machine" problem)</pre>
This model suffers from several critical issues:

* '''Dependency Hell''': Different applications require different, potentially conflicting library versions
* '''Configuration Drift''': Development, staging, and production environments gradually diverge
* '''Snowflake Servers''': Each server becomes unique and unreproducible
* '''Slow Deployment''': Setting up a new environment can take hours or days
* '''Poor Resource Utilization''': Applications can't share servers due to dependency conflicts

'''Container-Based Deployment Model:'''

<pre>1. Developer creates Dockerfile specifying exact environment
2. Build process creates immutable container image with all dependencies
3. Image tested in CI/CD pipeline (identical to production)
4. Image deployed to any server with Docker installed
5. Container starts in seconds with guaranteed-identical environment
6. Multiple isolated applications run on same host without conflicts</pre>
This model provides:

* '''Immutable Infrastructure''': Images never change after building; deploy new versions rather than modifying running systems
* '''Reproducibility''': Development environment = testing environment = production environment
* '''Portability''': "Build once, run anywhere" (laptop, data center, cloud)
* '''Efficiency''': Run 10-100 containers on a single host (vs. 5-10 VMs)
* '''Rapid Deployment''': Start containers in milliseconds vs. minutes for VMs
* '''Microservices Architecture''': Enables decomposing monoliths into independently deployable services

This shift has revolutionized software engineering, enabling modern DevOps practices, continuous deployment, and cloud-native architectures. Companies like Netflix, Uber, and Airbnb run millions of containers to serve billions of requests daily.


=== Containers vs Virtual Machines ===

Understanding the architectural difference between containers and virtual machines is crucial for appreciating why containers have become the dominant deployment model.

'''Virtual Machine Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Libraries │ │ Libraries │ │ Libraries │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Guest OS │ │ Guest OS │ │ Guest OS │
│ (Kernel) │ │ (Kernel) │ │ (Kernel) │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
Hypervisor (VMware, KVM, Xen)
─────────────────────────────────────────────────
Host Operating System & Kernel
─────────────────────────────────────────────────
Hardware</pre>
'''Characteristics:'''

* Each VM runs a complete guest operating system with its own kernel
* Hypervisor emulates hardware, providing virtual CPUs, RAM, disks, NICs
* Strong isolation (separate kernels mean vulnerabilities in one VM don't affect others)
* Heavy resource consumption (each OS kernel needs 1-2GB RAM)
* Slow startup (boot entire OS: 30-60 seconds)
* Large disk footprint (each VM stores complete OS: 1-10GB)

'''Container Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Libraries │ │ Libraries │ │ Libraries │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
Container Runtime (Docker Engine)
─────────────────────────────────────────────────
Host Operating System & Shared Kernel
─────────────────────────────────────────────────
Hardware</pre>
'''Characteristics:'''

* All containers share the host's kernel (no guest OS needed)
* Container runtime manages namespace and cgroup isolation
* Lightweight isolation (namespaces separate processes, but they're still just processes)
* Minimal resource overhead (containers use only incremental memory beyond their application)
* Fast startup (start process in isolated namespace: milliseconds)
* Small disk footprint (layered filesystem shares common base images: 10-100MB incremental)

'''The Trade-off:'''

Virtual machines provide '''stronger security isolation''' at the cost of '''resource efficiency'''. If your threat model requires complete kernel isolation (e.g., multi-tenant cloud providers hosting untrusted code), VMs are appropriate.

Containers provide '''lighter-weight isolation''' with '''much better resource efficiency'''. If you're running your own applications on your own infrastructure, containers are usually the right choice. You can run 10-100 containers on hardware that would support only 5-10 VMs.

'''An Important Insight:''' When you run <code>ps aux</code> on the host, you see container processes. They're not hidden inside separate kernels like VM processes would be. This demonstrates that containers are just isolated processes on the host—the kernel makes them appear isolated through namespaces, but they're fundamentally just processes.

This is both a feature (efficiency, observability) and a constraint (shared kernel means a kernel vulnerability could affect all containers). Modern container security practices use defense-in-depth: namespaces + cgroups + seccomp + AppArmor/SELinux + user namespaces to create multiple security layers.


== Prerequisites ==


=== System Requirements ===

* '''Operating System''': Linux-based system (Ubuntu 20.04+ recommended, but Debian, Fedora, CentOS also supported)
* '''RAM''': Minimum 2GB, 4GB recommended for comfortable operation
* '''Disk Space''': At least 20GB free (Docker images and container layers consume significant space)
* '''CPU''': Any modern x86_64 or ARM64 processor
* '''Privileges''': Root access via <code>sudo</code> (required for Docker installation and initial setup)
* '''Kernel''': Minimum Linux kernel 3.10 (kernel 4.0+ recommended for full feature support)

'''Check your kernel version:'''

<syntaxhighlight lang="bash">uname -r</syntaxhighlight>
If below 3.10, you'll need to update your kernel before proceeding.

'''Check available disk space:'''

<syntaxhighlight lang="bash">df -h /var/lib/docker</syntaxhighlight>
Docker stores images and containers in <code>/var/lib/docker</code> by default. Ensure you have sufficient space.


=== Required Packages ===

Before beginning, ensure the following packages are installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg \
lsb-release \
bridge-utils \
net-tools</syntaxhighlight>
'''Package descriptions:'''

* <code>apt-transport-https</code>: Enables apt to retrieve packages over HTTPS
* <code>ca-certificates</code>: Common CA certificates for SSL verification
* <code>curl</code>: Command-line tool for transferring data (used to download Docker's GPG key)
* <code>gnupg</code>: GNU Privacy Guard for verifying package signatures
* <code>lsb-release</code>: Provides Linux Standard Base version information (used to detect Ubuntu version)
* <code>bridge-utils</code>: Tools for managing bridge devices (<code>brctl</code> command)
* <code>net-tools</code>: Legacy networking tools (<code>ifconfig</code>, <code>netstat</code>) for compatibility


=== Knowledge Prerequisites ===

This lab builds directly on concepts from previous labs. You should be comfortable with:

'''From Lab 2 (Filesystems):'''

* Filesystem hierarchy and directory structure
* Mount points and the <code>mount</code> command
* Understanding of <code>/</code>, <code>/etc</code>, <code>/var</code>, <code>/usr</code> purposes
* File permissions and ownership (<code>chmod</code>, <code>chown</code>)
* Symbolic links and filesystem navigation

'''From Lab 3 (Processes and Jobs):'''

* Process IDs (PIDs) and process hierarchy
* Parent-child process relationships
* <code>ps aux</code> command and process listing
* Foreground vs. background processes
* Process signals (SIGTERM, SIGKILL)

'''From Lab 4 (Users, Groups, and Permissions):'''

* User IDs (UIDs) and group IDs (GIDs)
* Root vs. unprivileged users
* <code>sudo</code> for privilege escalation
* File and directory permissions (read, write, execute)
* Security implications of running processes as root

'''From Lab 7 (Network Fundamentals):'''

* Network interfaces and IP addresses
* Bridges and virtual ethernet (veth) pairs
* Subnets and CIDR notation
* Routing tables and default gateways
* Network Address Translation (NAT)
* '''Network namespaces''' (<code>ip netns add</code>, <code>ip netns exec</code>)

This is crucial—Docker networking uses the exact same mechanisms you built manually.

'''From Lab 8 (Transport and Security):'''

* TCP and UDP protocols
* Port numbers and socket addresses (IP:PORT)
* Client-server communication model
* The concept of listening vs. connecting
* TLS/SSL (Docker can use HTTPS for secure image distribution)

'''From Lab 9 (Application Protocols):'''

* HTTP/HTTPS protocols
* Reverse proxies and path-based routing
* DNS and hostname resolution
* Caddy web server configuration
* Multi-tier application architecture

You should also be comfortable with:

* Command-line text manipulation (<code>grep</code>, <code>awk</code>, <code>cut</code>, <code>sed</code>)
* Basic bash scripting (variables, loops, conditionals)
* Using multiple terminal windows simultaneously


== Theoretical Background ==


=== Linux Namespaces: The Foundation of Containers ===

In Labs 7-9, you worked extensively with network namespaces—one of seven namespace types provided by the Linux kernel. Every time you executed:

<syntaxhighlight lang="bash">sudo ip netns add red
sudo ip netns exec red ip addr show</syntaxhighlight>
You were creating an isolated network environment and executing commands within that isolated environment. The processes running in the <code>red</code> namespace could not see network interfaces, routes, or connections in other namespaces. This isolation is the fundamental mechanism that makes containers possible.

Docker extends this concept to six additional namespace types, providing complete process isolation. Understanding namespaces is essential to understanding containers—they are not optional background knowledge, but rather the core technology that defines what a container is.


==== The Seven Namespace Types ====

'''1. Network Namespace (<code>net</code>)'''

You know this namespace intimately from Labs 7-9. When you created the <code>red</code> and <code>blue</code> namespaces, you were creating isolated network stacks.

'''What it isolates:'''

* Network interfaces (lo, eth0, wlan0, etc.)
* IP addresses (each namespace has its own IPs)
* Routing tables (<code>ip route show</code> output differs per namespace)
* Firewall rules (iptables/nftables rules are namespace-specific)
* Network sockets and ports (multiple processes in different namespaces can bind to the same port number)

'''Connection to Lab 7:'''

In Lab 7, you manually created network namespaces:

<syntaxhighlight lang="bash">sudo ip netns add red # Create isolated network stack
sudo ip netns exec red ip link show # View interfaces in that namespace</syntaxhighlight>
Docker does exactly this when you run a container, but also creates six other namespace types simultaneously.

'''Example implications:'''

* Container A can listen on port 80, Container B can listen on port 80—no conflict
* Container A cannot see Container B's network connections (<code>ss -tuna</code> shows only its own)
* Each container has its own localhost (127.0.0.1) that's separate from the host

'''2. PID Namespace (<code>pid</code>)'''

The PID namespace isolates the process ID number space. This is related to what you learned in Lab 3 about process management.

'''What it isolates:'''

* Process IDs—processes in different PID namespaces can have the same PID
* Process visibility—processes can only see other processes in the same PID namespace
* PID 1 (init process)—each PID namespace has its own PID 1

'''How it works:'''

The kernel maintains a separate process tree for each PID namespace. When you create a PID namespace and start a process in it:

* Inside the namespace, that process is PID 1 (like an init system)
* Outside the namespace, that same process has a different PID (e.g., 12345)
* Processes inside cannot see processes outside their namespace tree

'''Example:'''

<syntaxhighlight lang="bash"># On the host
ps aux | wc -l
# Output: 237 processes

# Inside a container
docker exec container ps aux | wc -l
# Output: 5 processes</syntaxhighlight>
The container's processes think they're the only processes on the system. They cannot see the host's other 232 processes.

'''3. Mount Namespace (<code>mnt</code>)'''

The mount namespace isolates the filesystem mount table. This relates directly to Lab 2 where you learned about filesystems and mounting.

'''What it isolates:'''

* Mount points—what is mounted at <code>/</code>, <code>/tmp</code>, <code>/var</code>, etc.
* Root filesystem—each namespace can have a completely different root directory
* Mount propagation—mounts in one namespace don't affect others (by default)

'''How it works:'''

When you create a mount namespace, the new namespace inherits a copy of the parent's mount table. But subsequent mounts/unmounts in the child don't affect the parent.

Containers use this to provide a completely different filesystem:

<syntaxhighlight lang="bash"># On host (Ubuntu)
ls /
bin boot dev etc home lib ...

# In container (Fedora)
docker exec fedora ls /
bin boot dev etc home lib ... # Different files!</syntaxhighlight>
Both see <code>/etc</code>, but they're seeing different directories. The container's <code>/etc/os-release</code> shows Fedora, while the host's shows Ubuntu.

'''Technical implementation:'''

Docker uses OverlayFS (covered later) to construct the container's root filesystem from image layers, then uses pivot_root or chroot to make that directory appear as <code>/</code> to the container's processes.

'''4. UTS Namespace (<code>uts</code>)'''

UTS stands for "Unix Timesharing System"—a historical name. The UTS namespace isolates hostname and domain name.

'''What it isolates:'''

* System hostname (<code>hostname</code> command output)
* Domain name (NIS domain name)

'''How it works:'''

Each UTS namespace can set its own hostname independently of other namespaces.

<syntaxhighlight lang="bash"># On host
hostname
# Output: myserver.example.com

# In container
docker exec container hostname
# Output: a1b2c3d4e5f6 (container ID)</syntaxhighlight>
Containers typically use the container ID as hostname by default, but you can override with <code>--hostname</code>:

<syntaxhighlight lang="bash">docker run --hostname=webserver nginx</syntaxhighlight>
'''5. IPC Namespace (<code>ipc</code>)'''

The IPC namespace isolates System V Inter-Process Communication resources. This relates to Lab 6 where you learned about IPC mechanisms.

'''What it isolates:'''

* System V message queues
* System V semaphore sets
* System V shared memory segments
* POSIX message queues (in <code>/dev/mqueue</code>)

'''Connection to Lab 6:'''

In Lab 6, you learned that processes can communicate via shared memory, message queues, and semaphores. The IPC namespace ensures that processes in different namespaces cannot access each other's IPC objects, even if they use the same IPC keys.

'''Example:'''

<syntaxhighlight lang="bash"># Container A creates shared memory segment with key 1234
docker exec containerA ipcmk -M 1024 -p 1234

# Container B tries to access it
docker exec containerB ipcs -m -k 1234
# Output: no segment found (different IPC namespace)</syntaxhighlight>
'''6. User Namespace (<code>user</code>)'''

The user namespace isolates user IDs (UIDs) and group IDs (GIDs). This is the most complex namespace and provides significant security benefits.

'''What it isolates:'''

* User IDs—UID 0 inside namespace can map to UID 100000 outside
* Group IDs—similar mapping for GIDs
* Capabilities—process can have capabilities inside namespace but not outside
* Security attributes—AppArmor/SELinux contexts

'''How it works:'''

User namespaces allow UID/GID mapping. A process can be root (UID 0) inside the namespace but unprivileged (e.g., UID 100000) outside.

<pre>Inside Container: UID 0 (root)
↓ mapping
Outside Container: UID 100000 (unprivileged)</pre>
'''Security benefit:'''

Even if an attacker compromises a container and gains root privileges inside the container, they're still unprivileged on the host. If they escape the container, they cannot access files owned by actual root.

'''Docker's approach:'''

By default, many Docker configurations share the host's user namespace (for simplicity and compatibility). Rootless Docker and user-remapped Docker use separate user namespaces for enhanced security.

'''7. Cgroup Namespace (<code>cgroup</code>)'''

The cgroup namespace isolates the view of the cgroup hierarchy. Note this is different from cgroups themselves (which we'll cover separately).

'''What it isolates:'''

* View of <code>/proc/self/cgroup</code>
* View of <code>/sys/fs/cgroup</code> hierarchy
* Ability to see other containers' resource constraints

'''How it works:'''

Without cgroup namespaces, a process can read <code>/proc/self/cgroup</code> and see the full path to its cgroup, revealing information about the container orchestration system.

With cgroup namespaces, the process sees itself at the root of the cgroup tree, hiding the real hierarchy.

'''Note:''' This namespace isolates the ''view'' of cgroups, not the enforcement of resource limits. Resource limits are enforced by cgroups themselves (covered in section 4.5).


==== Namespace Identifiers: Understanding /proc/PID/ns/ ====

Every process has a directory at <code>/proc/PID/ns/</code> containing symbolic links to namespace identifiers. These links reveal which namespaces the process belongs to.

'''Examining namespace identifiers:'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/</syntaxhighlight>
'''Example output:'''

<pre>lrwxrwxrwx 1 root root 0 Dec 12 10:30 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 net -> 'net:[4026531992]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 uts -> 'uts:[4026531838]'</pre>
'''Understanding the format:'''

Each symlink follows the pattern: <code>namespace_type:[inode_number]</code>

The '''inode number''' is the critical piece of information. It uniquely identifies that specific namespace instance. Think of it as a "namespace ID."

'''Key principle: Same inode = Shared namespace, Different inode = Isolated namespace'''

'''Example from Lab 7:'''

When you created network namespaces in Lab 7, each had a unique network namespace inode:

<syntaxhighlight lang="bash"># Host process
sudo ls -la /proc/$$/ns/net
net -> 'net:[4026531992]' # Host's network namespace

# Process in red namespace
sudo ip netns exec red ls -la /proc/$$/ns/net
net -> 'net:[4026532145]' # Different inode = isolated!

# Process in blue namespace
sudo ip netns exec blue ls -la /proc/$$/ns/net
net -> 'net:[4026532147]' # Also different = also isolated!</syntaxhighlight>
'''Comparing container to host:'''

<syntaxhighlight lang="bash"># Get container's PID on host
docker inspect container --format '{{.State.Pid}}'
# Example output: 12345

# View container's namespaces
sudo ls -la /proc/12345/ns/net
# Output: net -> 'net:[4026533672]'

# View host's namespace
sudo ls -la /proc/$$/ns/net
# Output: net -> 'net:[4026531992]'

# Different inodes! Container is isolated.</syntaxhighlight>
'''Namespace sharing:'''

Sometimes containers intentionally share namespaces. For example:

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
This container shares the host's network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]' # Same as host!</syntaxhighlight>
'''Using namespace identifiers:'''

These symlinks aren't just informational—you can actually use them to enter namespaces:

<syntaxhighlight lang="bash">sudo nsenter --net=/proc/12345/ns/net ip addr show</syntaxhighlight>
This command enters the network namespace of PID 12345 and runs <code>ip addr show</code> inside that namespace. This is how <code>docker exec</code> works under the hood—it uses <code>nsenter</code> to join the container's namespaces.

'''Summary table:'''

{| class="wikitable"
|-
! Namespace Type
! What It Isolates
! Lab Connection
|-
| <code>net</code>
| Network stack (interfaces, IPs, routes, ports)
| Lab 7: You built this manually!
|-
| <code>pid</code>
| Process IDs and process tree
| Lab 3: Process management
|-
| <code>mnt</code>
| Filesystem mounts and root directory
| Lab 2: Mounting and filesystems
|-
| <code>uts</code>
| Hostname and domain name
| -
|-
| <code>ipc</code>
| Shared memory, message queues, semaphores
| Lab 6: IPC mechanisms
|-
| <code>user</code>
| User and group IDs, capabilities
| Lab 4: Users and permissions
|-
| <code>cgroup</code>
| View of cgroup hierarchy
| -
|}


=== Container Images vs Running Containers ===

This distinction is fundamental to understanding Docker and is often a source of confusion.

'''Container Image:'''

A container image is a '''read-only template''' consisting of:

# '''A root filesystem''': All files and directories that will appear in the container (applications, libraries, configuration files)
# '''Metadata''': Information about how to run the container (default command, environment variables, exposed ports, volumes)
# '''Layers''': The filesystem is composed of multiple read-only layers (explained in section 4.4)

'''Characteristics:'''

* '''Immutable''': Once built, an image never changes
* '''Shareable''': Multiple containers can use the same image
* '''Versionable''': Images can have tags (e.g., <code>nginx:1.21</code>, <code>nginx:latest</code>)
* '''Distributable''': Images can be pushed to/pulled from registries (Docker Hub, private registries)
* '''Stored on disk''': Images consume storage even when not running

'''Running Container:'''

A running container is an '''instance''' of an image—a process (or process tree) running in isolated namespaces with its own writable filesystem layer.

'''Characteristics:'''

* '''Ephemeral''': State is lost when the container is removed (unless using volumes)
* '''Mutable''': Can make changes inside the container (install packages, create files)
* '''Process-based''': A container is fundamentally just a Linux process in isolated namespaces
* '''Short-lived''': Containers are typically created, used, and destroyed frequently
* '''Stateful during runtime''': Maintains state while running, but that state disappears on removal

'''Example to illustrate:'''

<syntaxhighlight lang="bash"># Pull an image (download the template)
docker pull nginx

# The image now exists on disk
docker images
# Output shows: nginx latest a1b2c3d4 100MB

# Start first container from this image
docker run -d --name web1 nginx

# Start second container from the same image
docker run -d --name web2 nginx

# Both containers share the same base image filesystem
# But each has its own writable layer and separate namespaces</syntaxhighlight>
Now you have:

* '''One image''' (nginx:latest) on disk
* '''Two containers''' (web1 and web2) running as separate processes
* Each container has its own PID namespace, network namespace, etc.
* Changes in web1 don't affect web2 (isolated writable layers)

'''Verification:'''

<syntaxhighlight lang="bash"># Modify web1
docker exec web1 bash -c "echo 'Hello from web1' > /usr/share/nginx/html/test.txt"

# Check web1
docker exec web1 cat /usr/share/nginx/html/test.txt
# Output: Hello from web1

# Check web2
docker exec web2 cat /usr/share/nginx/html/test.txt
# Output: cat: /usr/share/nginx/html/test.txt: No such file or directory</syntaxhighlight>
The file exists in web1 but not in web2, even though they're from the same image. Each container has its own writable layer.

'''Image to Container Relationship Diagram:'''

<pre> [nginx Image]
(Read-only)
|
┌─────────┴─────────┐
↓ ↓
[Container 1] [Container 2]
(Writable layer) (Writable layer)
(PID namespace) (PID namespace)
(Net namespace) (Net namespace)
(Isolated) (Isolated)</pre>
'''Filesystem perspective:'''

<pre>Image Layers (read-only, shared):
├─ Layer 3: nginx files
├─ Layer 2: nginx dependencies
└─ Layer 1: Base OS (Debian)

Container 1 (writable, unique):
└─ Writable layer: Changes made in container 1

Container 2 (writable, unique):
└─ Writable layer: Changes made in container 2</pre>
'''Why this design?'''

* '''Efficiency''': 100 containers from the same image share one copy of the base filesystem
* '''Speed''': Starting a container doesn't require copying files—just create a new writable layer
* '''Consistency''': All containers from an image start with identical state
* '''Immutability''': Encourages treating containers as disposable—don't modify running containers, rebuild images instead


=== Container Lifecycle and Ephemeral Nature ===

Understanding the container lifecycle is essential for proper container usage. Containers are designed to be ephemeral—short-lived and replaceable.

'''Container States:'''

<pre>┌─────────┐
│ Created │ (Container exists but not running)
└────┬────┘
│ docker start
↓
┌─────────┐
│ Running │ (Processes executing in isolated namespaces)
└────┬────┘
│ docker stop (SIGTERM, then SIGKILL after timeout)
↓
┌─────────┐
│ Stopped │ (Processes terminated, filesystem layer persists)
└────┬────┘
│ docker start (restart with same writable layer)
↓
┌─────────┐
│ Running │
└────┬────┘
│ docker rm (delete container)
↓
┌─────────┐
│ Removed │ (Container and writable layer deleted forever)
└─────────┘</pre>
'''Key lifecycle commands:'''

<syntaxhighlight lang="bash"># Create and start in one step (most common)
docker run nginx

# Create without starting
docker create --name test nginx

# Start existing stopped container
docker start test

# Stop running container (SIGTERM to main process)
docker stop test

# Force stop (SIGKILL)
docker kill test

# Remove stopped container
docker rm test

# Remove running container (force)
docker rm -f test</syntaxhighlight>
'''The Ephemeral Nature:'''

By default, all changes made inside a container are lost when the container is removed:

<syntaxhighlight lang="bash"># Start container
docker run -d --name demo nginx

# Make changes inside
docker exec demo bash -c "echo 'My data' > /tmp/important.txt"
docker exec demo cat /tmp/important.txt
# Output: My data

# Stop and remove container
docker stop demo
docker rm demo

# Try to access the data
docker run --name demo2 nginx
docker exec demo2 cat /tmp/important.txt
# Output: cat: /tmp/important.txt: No such file or directory
# THE DATA IS GONE!</syntaxhighlight>
'''Why ephemeral?'''

This might seem like a limitation, but it's actually a feature that enables important practices:

# '''Immutable Infrastructure''': Don't patch running systems; deploy new versions
# '''Reproducibility''': Every deployment starts from a known state
# '''Testing''': Test environments are identical to production
# '''Rollback''': Easy to roll back to previous image version
# '''Scaling''': Identical containers can be created/destroyed dynamically

'''When you need persistence:'''

For data that must survive container restarts, use '''volumes''' (covered in section 4.7):

<syntaxhighlight lang="bash"># Create named volume
docker volume create mydata

# Use volume in container
docker run -v mydata:/data nginx

# Data in /data survives container removal</syntaxhighlight>
'''Container lifecycle best practices:'''

* '''Treat containers as cattle, not pets''': Don't name them, don't SSH into them to debug, don't manually configure them
* '''Logs go to stdout/stderr''': Not to files inside the container (so <code>docker logs</code> can capture them)
* '''Configuration via environment variables''': Not by editing files inside the container
* '''Data goes in volumes''': Not in the container's writable layer
* '''Short-lived processes''': Containers should start quickly and shut down gracefully

'''Connection to Lab 3:'''

In Lab 3, you learned about process lifecycle (start, run, terminate). Containers follow a similar lifecycle, but operate at a higher level of abstraction—each container lifecycle event actually involves creating/destroying multiple processes in isolated namespaces.


=== Control Groups (cgroups): Resource Limiting ===

Control groups (cgroups) are a Linux kernel feature that limits, accounts for, and isolates resource usage (CPU, memory, disk I/O, network) of process groups. Without cgroups, a runaway container could consume all CPU or memory, starving other containers and crashing the host.

'''The Problem:'''

Without resource limits:

<syntaxhighlight lang="bash"># Malicious or buggy container
docker run -d evil-container

# This container's process could:
# - Consume 100% CPU (slow down everything else)
# - Allocate all available RAM (trigger OOM killer on host)
# - Fill up disk space (crash other containers)
# - Monopolize network bandwidth</syntaxhighlight>
This is unacceptable in multi-tenant environments. You need resource isolation.

'''The Solution: cgroups'''

Cgroups organize processes into hierarchical groups with configurable resource limits. The kernel enforces these limits, preventing processes from exceeding their allocation.

'''Cgroup Controllers:'''

The Linux kernel provides several cgroup controllers, each managing a different resource type:

# '''cpu''': Limits CPU time
#* CPU shares (relative priority)
#* CPU quotas (hard limits)
#* CPU affinity (pin to specific cores)
# '''memory''': Limits RAM usage
#* Hard limits (container killed if exceeded)
#* Soft limits (reclaim memory under pressure)
#* Swap limits
# '''blkio''': Limits disk I/O
#* Read/write bandwidth limits
#* I/O operation rate limits
# '''net_cls/net_prio''': Network bandwidth control
#* Traffic classification
#* Priority settings
# '''pids''': Limits number of processes
#* Prevents fork bombs
# '''cpuset''': Assigns specific CPUs and memory nodes
#* NUMA awareness

'''Docker's cgroup integration:'''

When you start a container with resource limits, Docker configures the appropriate cgroups:

<syntaxhighlight lang="bash">docker run --memory=512m --cpus=1.5 nginx</syntaxhighlight>
Docker creates a cgroup hierarchy at <code>/sys/fs/cgroup/</code> and configures:

* <code>memory.limit_in_bytes = 536870912</code> (512MB)
* <code>cpu.cfs_quota_us</code> and <code>cpu.cfs_period_us</code> to enforce 1.5 CPUs

'''Viewing cgroup settings:'''

<syntaxhighlight lang="bash"># Get container's PID
docker inspect container --format '{{.State.Pid}}'
# Example: 12345

# View memory limit
cat /sys/fs/cgroup/memory/docker/12345/memory.limit_in_bytes
# Output: 536870912

# View CPU quota
cat /sys/fs/cgroup/cpu/docker/12345/cpu.cfs_quota_us
# Output: 150000 (1.5 CPUs)</syntaxhighlight>
'''Common resource limit flags:'''

<syntaxhighlight lang="bash"># Memory limits
--memory=512m # Hard limit: 512MB RAM
--memory-reservation=256m # Soft limit: try to stay under 256MB
--memory-swap=512m # Total memory+swap limit

# CPU limits
--cpus=1.5 # Use at most 1.5 CPU cores
--cpu-shares=512 # Relative CPU priority (default 1024)
--cpuset-cpus=0,1 # Pin to CPU cores 0 and 1

# I/O limits
--device-read-bps=/dev/sda:10mb # Limit read bandwidth
--device-write-bps=/dev/sda:10mb # Limit write bandwidth

# Process limits
--pids-limit=100 # Max 100 processes in container</syntaxhighlight>
'''Testing memory limits:'''

<syntaxhighlight lang="bash"># Run container with 256MB memory limit
docker run -it --memory=256m ubuntu bash

# Inside container, try to allocate 512MB
# (requires 'stress' tool)
apt-get update && apt-get install -y stress
stress --vm 1 --vm-bytes 512M

# Container is killed when exceeding limit
# Output: stress: FAIL: [1] (415) <-- worker 7 got signal 9
# Signal 9 = SIGKILL (OOM killer)</syntaxhighlight>
'''Why cgroups are essential:'''

# '''Multi-tenancy''': Run untrusted workloads safely
# '''Quality of Service''': Guarantee resources for critical applications
# '''Fair sharing''': Prevent one container from monopolizing resources
# '''Predictability''': Know exactly how much resources each container can use
# '''Cost control''': In cloud environments, map cgroups to billing

'''cgroup vs namespace distinction:'''

* '''Namespaces''': Provide ''isolation''
* '''cgroups''': Provide ''resource limits''

Both are necessary for containers. Namespaces prevent containers from seeing each other; cgroups prevent containers from starving each other.


=== Docker Networking: Bridges, veth Pairs, and NAT ===

Docker networking should feel familiar—it uses the exact same mechanisms you built manually in Lab 7. The primary difference is automation: Docker sets up bridges, veth pairs, routes, and NAT rules automatically.

'''Default Docker Network Architecture:'''

When you install Docker, it creates a default bridge network:

<pre>┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Container A │ │ Container B │ │ Container C │
│ 172.17.0.2 │ │ 172.17.0.3 │ │ 172.17.0.4 │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│eth0 │eth0 │eth0
│ │ │
(veth pair) (veth pair) (veth pair)
│ │ │
┌────┴───────────────────┴───────────────────┴────┐
│ docker0 Bridge │
│ 172.17.0.1/16 │
└────────────────────┬─────────────────────────────┘
│
[Host eth0]
│
[Internet]
(via NAT/MASQUERADE)</pre>
'''Component breakdown (all from Lab 7!):'''

'''1. Bridge Interface (<code>docker0</code>)'''

Docker automatically creates a bridge interface when installed:

<syntaxhighlight lang="bash">ip addr show docker0</syntaxhighlight>
'''Expected output:'''

<pre>3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 02:42:8f:a3:f1:2a brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0</pre>
This is '''exactly like <code>br-lab</code>''' from Lab 7:

* Bridge interface acting as virtual switch
* Assigned IP address 172.17.0.1
* Subnet 172.17.0.0/16 (65,536 addresses available)

'''2. veth Pairs'''

For each container, Docker creates a veth pair:

<syntaxhighlight lang="bash">ip link show | grep veth</syntaxhighlight>
'''Expected output:'''

<pre>8: veth7a3f2b1@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0
10: veth9d4e8c2@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0</pre>
'''Decoding this:'''

* <code>veth7a3f2b1@if7</code>: One end of veth pair, connected to bridge (<code>master docker0</code>)
* <code>@if7</code>: Paired with interface index 7 (inside container)

This is '''exactly what you did in Lab 7:'''

<syntaxhighlight lang="bash">sudo ip link add v-host type veth peer name v-client</syntaxhighlight>
Docker does the same thing, automatically.

'''3. Container Network Namespace'''

Each container has its own network namespace (you built these manually in Lab 7!):

<syntaxhighlight lang="bash"># View container's network interfaces
docker exec container ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo

7: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0</pre>
The container sees:

* <code>lo</code>: Its own loopback interface
* <code>eth0@if8</code>: Its end of the veth pair (paired with host's interface index 8)
* IP address from docker0 subnet

'''4. IP Address Assignment'''

Docker acts as a simple DHCP-like service, assigning IPs sequentially:

* First container: 172.17.0.2
* Second container: 172.17.0.3
* Third container: 172.17.0.4
* etc.

'''5. Routing in Container'''

Check the container's routing table:

<syntaxhighlight lang="bash">docker exec container ip route show</syntaxhighlight>
'''Expected output:'''

<pre>default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2</pre>
'''Translation:'''

* Default route: Send all traffic to 172.17.0.1 (the bridge) for routing to internet
* Local route: 172.17.0.0/16 is directly reachable via eth0

This is '''exactly the routing you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo ip netns exec red ip route add default via 10.0.0.1</syntaxhighlight>
'''6. NAT for Internet Access'''

Docker automatically configures iptables/nftables NAT rules (MASQUERADE) so containers can reach the internet:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep MASQUERADE</syntaxhighlight>
'''Expected output:'''

<pre>MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0</pre>
This is '''exactly the NAT you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE</syntaxhighlight>
'''7. Port Mapping (<code>-p</code> flag)'''

When you use <code>-p 8080:80</code>, Docker sets up Destination NAT (DNAT):

<syntaxhighlight lang="bash">docker run -d -p 8080:80 nginx</syntaxhighlight>
Docker adds an iptables DNAT rule:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep DNAT</syntaxhighlight>
'''Expected output:'''

<pre>DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80</pre>
'''Translation:''' Traffic arriving at host port 8080 is redirected to 172.17.0.2:80

This is also NAT, specifically DNAT (Destination NAT). You encountered source NAT (SNAT/MASQUERADE) in Lab 7.

'''Container-to-Container Communication'''

Containers on the same bridge can communicate directly:

<syntaxhighlight lang="bash"># Container A pings Container B
docker exec containerA ping 172.17.0.3</syntaxhighlight>
The packet flow:

# Container A sends to 172.17.0.2 (Container B's IP)
# Packet goes out Container A's eth0 (through veth pair)
# Arrives on docker0 bridge
# Bridge forwards to veth pair for Container B
# Packet arrives at Container B's eth0

'''No routing through host networking needed'''—the bridge forwards directly (Layer 2 switching).

'''Custom Networks'''

You can create custom bridge networks:

<syntaxhighlight lang="bash">docker network create --subnet=10.20.0.0/24 mynet</syntaxhighlight>
Docker creates a new bridge interface (e.g., <code>br-abc123def456</code>) with subnet 10.20.0.0/24.

Containers on different networks are isolated:

<syntaxhighlight lang="bash">docker run -d --network=mynet --name=isolated nginx</syntaxhighlight>
This container is on <code>mynet</code>, not <code>docker0</code>, so it cannot communicate with containers on the default bridge (different Layer 2 segment).

'''DNS Resolution Between Containers'''

Docker provides automatic DNS resolution for container names within custom networks:

<syntaxhighlight lang="bash">docker network create mynet
docker run -d --network=mynet --name=web nginx
docker run -d --network=mynet --name=app alpine

# From app container
docker exec app ping web
# Resolves 'web' to web container's IP address!</syntaxhighlight>
Docker runs an embedded DNS server (listening on 127.0.0.11 inside containers) that resolves container names to IPs.

'''Network Modes:'''

Docker supports several network modes:

* '''bridge''' (default): Container on docker0 bridge (or custom bridge)
* '''host''': Container shares host's network namespace (no isolation)
* '''none''': No networking (container has only loopback)
* '''container:name''': Share another container's network namespace

'''Example: host mode'''

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
The container's network namespace inode is the same as the host's:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]' # Same as host!</syntaxhighlight>
Container sees all host's network interfaces and can bind to any port on any interface.

'''Summary:'''

Docker networking uses:

* Bridges (like <code>br-lab</code> from Lab 7)
* veth pairs (like <code>v-host</code> ↔ <code>v-client</code> from Lab 7)
* Network namespaces (like <code>red</code> and <code>blue</code> from Lab 7)
* Routing tables and default routes
* NAT/MASQUERADE for internet access
* DNAT for port mapping


=== Volumes: Persistent and Shared Storage ===

By default, container filesystems are ephemeral—all changes are lost when the container is removed. For data that must persist (databases, user uploads, logs), Docker provides volumes.

'''The Problem:'''

<syntaxhighlight lang="bash"># Start database container
docker run -d --name db postgres

# Database writes data
docker exec db psql -c "CREATE DATABASE myapp;"

# Stop and remove container
docker rm -f db

# Data is GONE FOREVER!</syntaxhighlight>
This is unacceptable for stateful applications.

'''The Solution: Volumes'''

Volumes are directories on the host that are mounted into containers. Data written to volumes persists beyond container lifecycle.

'''Two Volume Types:'''

'''1. Named Volumes (Docker-managed):'''

Docker manages the volume storage location.

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# Use in container
docker run -v mydata:/data nginx

# Data written to /data inside container is stored in:
# /var/lib/docker/volumes/mydata/_data (on host)</syntaxhighlight>
'''Advantages:'''

* Docker manages storage location
* Portable across hosts (can be backed up, restored)
* Works with volume plugins (NFS, cloud storage)

'''Best practice:''' Use named volumes for production databases, critical data.

'''2. Bind Mounts (Host directory):'''

Mount a host directory directly into the container.

<syntaxhighlight lang="bash"># Mount host directory into container
docker run -v /home/user/html:/usr/share/nginx/html nginx</syntaxhighlight>
Any changes in <code>/home/user/html</code> on the host are immediately visible in <code>/usr/share/nginx/html</code> inside the container, and vice versa.

'''Advantages:'''

* Direct access to files from host
* Useful for development (edit code on host, see changes in container immediately)
* No Docker management needed

'''Disadvantages:'''

* Tied to specific host filesystem paths
* Less portable
* Permissions can be tricky (host UID vs. container UID)

<syntaxhighlight lang="bash"># Docker essentially does:
mount --bind /var/lib/docker/volumes/mydata/_data /data</syntaxhighlight>
'''Volume Sharing Between Containers:'''

Multiple containers can share the same volume:

<syntaxhighlight lang="bash"># Create volume
docker volume create shared

# Container 1 writes
docker run -v shared:/data --name writer alpine sh -c "echo 'Hello' > /data/file.txt"

# Container 2 reads
docker run -v shared:/data --name reader alpine cat /data/file.txt
# Output: Hello</syntaxhighlight>
'''Use cases:'''

* Shared configuration between containers
* Log aggregation (multiple containers write logs to shared volume)
* Data processing pipelines (one container produces, another consumes)

'''Volume Lifecycle:'''

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# List volumes
docker volume ls

# Inspect volume
docker volume inspect mydata

# Remove volume (only if no containers using it)
docker volume rm mydata

# Remove all unused volumes
docker volume prune</syntaxhighlight>
'''Inspecting Volume Mounts:'''

<syntaxhighlight lang="bash">docker inspect container --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Example output:'''

<syntaxhighlight lang="json">[
{
"Type": "volume",
"Source": "/var/lib/docker/volumes/mydata/_data",
"Destination": "/data",
"Mode": "z",
"RW": true
}
]</syntaxhighlight>
'''Fields:'''

* <code>Type</code>: "volume" or "bind"
* <code>Source</code>: Host-side path
* <code>Destination</code>: Container-side path
* <code>RW</code>: Read-write (true) or read-only (false)

'''Read-Only Volumes:'''

For security, you can mount volumes read-only:

<syntaxhighlight lang="bash">docker run -v mydata:/data:ro nginx</syntaxhighlight>
Container can read <code>/data</code> but cannot write to it.

'''tmpfs Mounts (In-Memory Temporary Storage):'''

For sensitive data that should never touch disk:

<syntaxhighlight lang="bash">docker run --tmpfs /tmp:size=100m nginx</syntaxhighlight>
The <code>/tmp</code> directory is stored in RAM and disappears when the container stops.

'''Best Practices:'''

* '''Named volumes for databases''': Postgres, MySQL, MongoDB
* '''Bind mounts for development''': Code that you're actively editing
* '''tmpfs for secrets''': Temporary credentials, keys
* '''Volume plugins for cloud''': AWS EBS, Azure Disk, GCP Persistent Disk


== Laboratory Exercises ==

The following exercises build progressively, demonstrating how Docker automates the kernel-level primitives you mastered in previous labs. You will install Docker, inspect namespace isolation, explore interactive containers, configure persistent storage, and build a multi-container application with networking and resource limits.


=== Exercise A: Installing Docker ===

'''Objective:''' Install Docker Engine from the official Docker repository and configure it for non-root access.

'''Why the official repository?''' Ubuntu's default repositories often contain outdated Docker versions. The official Docker repository provides the latest stable releases with security updates and new features.

'''Step 1: Remove old Docker versions (if any)'''

If you previously installed Docker from Ubuntu's repositories or older Docker installations exist, remove them to avoid conflicts:

<syntaxhighlight lang="bash">sudo apt remove docker docker-engine docker.io containerd runc</syntaxhighlight>
It's safe to run this even if these packages aren't installed—apt will simply report they're not present.

'''Step 2: Install prerequisites'''

Install packages needed for adding Docker's repository:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg \
lsb-release</syntaxhighlight>
'''Step 3: Add Docker's GPG key'''

Docker signs its packages with a GPG key to ensure authenticity. Add this key to your system:

<syntaxhighlight lang="bash">sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg</syntaxhighlight>
'''What this does:'''

* Creates <code>/etc/apt/keyrings/</code> directory for storing repository keys
* Downloads Docker's GPG public key
* Converts it to binary format (<code>.gpg</code> file)
* Makes it readable by all users

'''Step 4: Add Docker repository to apt sources'''

<syntaxhighlight lang="bash">sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.gpg
EOF</syntaxhighlight>
'''What this does:'''

* Detects your CPU architecture (amd64, arm64, etc.)
* Detects your Ubuntu version codename (focal, jammy, etc.)
* Adds Docker's repository to apt's source list

'''Step 5: Install Docker Engine'''

Update package index and install Docker:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
docker-ce \
docker-ce-cli \
containerd.io \
docker-buildx-plugin \
docker-compose-plugin</syntaxhighlight>
'''Packages installed:'''

* <code>docker-ce</code>: Docker Community Edition engine (the main Docker daemon)
* <code>docker-ce-cli</code>: Docker command-line interface
* <code>containerd.io</code>: Container runtime that Docker uses under the hood
* <code>docker-buildx-plugin</code>: Extended build capabilities (multi-platform images)
* <code>docker-compose-plugin</code>: Docker Compose for multi-container applications

'''Step 6: Verify Docker installation'''

Check Docker version:

<syntaxhighlight lang="bash">sudo docker --version</syntaxhighlight>
'''Expected output:'''

<pre>Docker version 24.0.7, build afdd53b</pre>
Your version number may be different (newer), which is fine.

'''Step 7: Start and enable Docker service'''

Ensure Docker daemon starts on boot:

<syntaxhighlight lang="bash">sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
Check service status:

<syntaxhighlight lang="bash">sudo systemctl status docker</syntaxhighlight>
'''Expected output:'''

<pre>● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled)
Active: active (running) since Thu 2024-12-12 10:30:00 UTC; 5min ago</pre>
Look for <code>Active: active (running)</code>.

'''Step 8: Configure non-root Docker access'''

By default, only root can run Docker commands. To run Docker without <code>sudo</code>, add your user to the <code>docker</code> group:

<syntaxhighlight lang="bash">sudo usermod -aG docker $USER</syntaxhighlight>
'''Important:''' Log out and log back in for this change to take effect. Alternatively, you can run:

<syntaxhighlight lang="bash">newgrp docker</syntaxhighlight>
This starts a new shell with updated group membership.

'''Step 9: Verify non-root access'''

Test that you can run Docker without sudo:

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
If this works without errors, you've successfully installed Docker!

'''Expected output:'''

<pre>Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:4bd78111b6914a99dbc560e6a20eab57ff6655aea4a80c50b0c5491968cbc2e6
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/</pre>
'''What happened:'''

# Docker client (<code>docker</code> command) connected to Docker daemon (dockerd)
# Daemon checked local images—didn't find <code>hello-world</code>
# Daemon pulled <code>hello-world</code> image from Docker Hub (public registry)
# Daemon created container from image
# Container executed its program (printed the message)
# Container exited
# Output sent back to your terminal

'''Step 10: Clean up test container'''

List all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
You should see the hello-world container with status <code>Exited (0)</code>.

Remove it:

<syntaxhighlight lang="bash">docker rm $(docker ps -aq --filter "ancestor=hello-world")</syntaxhighlight>
Verify it's gone:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Deliverable A:'''

Provide screenshots showing:

# Output of <code>docker --version</code>
# Output of <code>sudo systemctl status docker</code> (showing Active: active (running))
# Output of <code>docker run hello-world</code> (the entire message)



=== Exercise B: Hello World and Namespace Inspection ===

'''Objective:''' Run your first container, understand the container lifecycle, and inspect the Linux kernel namespaces that provide container isolation—connecting directly to your work in Lab 7.


==== Part 1: Hello World ====

'''Step 1: Run the hello-world container (if not done in Exercise A)'''

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
We covered this in Exercise A, but let's examine what actually happened in more detail.

'''Step 2: List all containers'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:''' Nothing (empty list)

'''Why?''' The hello-world container ran, printed its message, and exited immediately. <code>docker ps</code> only shows running containers by default.

To see all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 hello-world "/hello" 10 seconds ago Exited (0) 8 seconds ago eager_tesla</pre>
'''Understanding the fields:'''

* '''CONTAINER ID''': Short hex identifier (first 12 chars of full 64-char ID)
* '''IMAGE''': Which image this container was created from
* '''COMMAND''': The process that ran inside the container (<code>/hello</code> executable)
* '''CREATED''': When the container was created
* '''STATUS''': Current state—<code>Exited (0)</code> means process exited with code 0 (success)
* '''PORTS''': Port mappings (none for hello-world)
* '''NAMES''': Random name if you don't specify one (Docker generates names like "eager_tesla", "hopeful_darwin")

'''Step 3: Inspect the container'''

Get detailed information about the container:

<syntaxhighlight lang="bash">docker inspect eager_tesla # Use your actual container name</syntaxhighlight>
This outputs a large JSON document with all container metadata. Let's extract specific fields:

<syntaxhighlight lang="bash"># Just the State section
docker inspect eager_tesla --format='{{json .State}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output (formatted):'''

<syntaxhighlight lang="json">{
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 0,
"StartedAt": "2024-12-12T10:35:00Z",
"FinishedAt": "2024-12-12T10:35:01Z"
}</syntaxhighlight>
'''Analysis:'''

* Container ran for about 1 second (started at :00, finished at :01)
* Exit code 0 (successful completion)
* PID is 0 (process has terminated; while running it had a real PID)

'''Step 4: View container logs'''

Even though the container exited, Docker saved its output:

<syntaxhighlight lang="bash">docker logs eager_tesla</syntaxhighlight>
Shows the hello-world message again. This demonstrates that Docker captures stdout/stderr from containers.

'''Step 5: Remove the container'''

Stopped containers still consume disk space (their writable layer persists). Remove it:

<syntaxhighlight lang="bash">docker rm eager_tesla</syntaxhighlight>
Verify removal:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
The container should be gone.


==== Part 2: Inspect Namespaces (Connect to Lab 7!) ====

Now let's run a longer-lived container and examine its namespace isolation—this directly connects to your hands-on work with network namespaces in Lab 7.

'''Step 1: Run a persistent container'''

<syntaxhighlight lang="bash">docker run -d --name inspector nginx</syntaxhighlight>
'''Flags explained:'''

* <code>-d</code>: Detached mode—run in background
* <code>--name inspector</code>: Give it a memorable name instead of random name

'''Expected output:'''

<pre>Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
Status: Downloaded newer image for nginx:latest
b7f9a8e6c4d3a1b2c5e8f9d2a7c4b6e8f3d9a2c1b4e7f8d3a5c2b1</pre>
The long hex string is the full 64-character container ID. Docker returns this after creating the container.

'''Step 2: Verify the container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b7f9a8e6c4d3 nginx "/docker-entrypoint.…" 10 seconds ago Up 8 seconds 80/tcp inspector</pre>
The container is running nginx web server.

'''Step 3: Get the container's PID on the host'''

Remember: containers are just processes. Let's find the PID:

<syntaxhighlight lang="bash">docker inspect inspector --format '{{.State.Pid}}'</syntaxhighlight>
'''Expected output:''' A number like <code>12345</code>

This is the process ID on the '''host''' system. Let's verify:

<syntaxhighlight lang="bash">ps aux | grep 12345</syntaxhighlight>
You should see nginx processes! The container is just a process with a fancy namespace wrapper.

'''Step 4: Examine the container's namespaces'''

This is the crucial step connecting to Lab 7. Replace 12345 with your actual PID:

<syntaxhighlight lang="bash">sudo ls -la /proc/12345/ns/</syntaxhighlight>
'''Expected output:'''

<pre>total 0
dr-x--x--x 2 root root 0 Dec 12 10:40 .
dr-xr-xr-x 9 root root 0 Dec 12 10:40 ..
lrwxrwxrwx 1 root root 0 Dec 12 10:40 cgroup -> 'cgroup:[4026533671]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 ipc -> 'ipc:[4026533669]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 mnt -> 'mnt:[4026533667]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 net -> 'net:[4026533672]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid -> 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid_for_children -> 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 uts -> 'uts:[4026533668]'</pre>
'''Analysis of namespace inodes:'''

Note the inode numbers (the numbers in brackets). Each represents a namespace instance.

'''Step 5: Compare with host's namespaces'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/net</syntaxhighlight>
'''Expected output:'''

<pre>lrwxrwxrwx 1 youruser youruser 0 Dec 12 10:40 net -> 'net:[4026531992]'</pre>
'''Critical observation:''' The container's network namespace inode (<code>4026533672</code>) is '''different''' from the host's (<code>4026531992</code>).

'''Step 6: Compare two containers'''

Start a second container:

<syntaxhighlight lang="bash">docker run -d --name inspector2 nginx</syntaxhighlight>
Get its PID:

<syntaxhighlight lang="bash">docker inspect inspector2 --format '{{.State.Pid}}'</syntaxhighlight>
Check its network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/NEW_PID/ns/net</syntaxhighlight>
'''Expected:''' A different inode number from both the host and <code>inspector</code> container!

'''Conclusion:''' Each container has its own isolated network namespace, just like the red and blue namespaces you created manually in Lab 7.

'''Step 7: Examine other namespaces'''

Let's check PID namespace isolation:

<syntaxhighlight lang="bash"># Host PID namespace
sudo ls -la /proc/$$/ns/pid

# Container PID namespace
sudo ls -la /proc/CONTAINER_PID/ns/pid</syntaxhighlight>
Different inodes = isolated process trees!

'''Step 8: User namespace (often shared)'''

<syntaxhighlight lang="bash"># Host user namespace
sudo ls -la /proc/$$/ns/user

# Container user namespace
sudo ls -la /proc/CONTAINER_PID/ns/user</syntaxhighlight>
'''Expected:''' Often the '''same''' inode number.

Many Docker configurations share the host's user namespace for simplicity. This means UID 0 in the container is UID 0 on the host (less secure, but more compatible).

For enhanced security, Docker can be configured to use separate user namespaces (rootless Docker), but that's beyond this lab's scope.

'''Step 9: Enter the container's namespace with nsenter'''

You can actually enter a container's namespaces using the <code>nsenter</code> command (this is how <code>docker exec</code> works!):

<syntaxhighlight lang="bash">sudo nsenter --target CONTAINER_PID --net ip addr show</syntaxhighlight>
This executes <code>ip addr show</code> inside the container's network namespace, showing the container's view of network interfaces.

'''Step 10: Clean up'''

<syntaxhighlight lang="bash">docker stop inspector inspector2
docker rm inspector inspector2</syntaxhighlight>

=== Deliverable B ===

Provide screenshots showing:

# Output of <code>docker run hello-world</code> (the full hello message)
# Output of <code>docker ps -a</code> showing the exited hello-world container with its random name
# Output of <code>docker inspect inspector --format '{{.State.Pid}}'</code> (showing the PID)
# Output of <code>sudo ls -la /proc/PID/ns/</code> for the inspector container (showing all namespaces)
# Side-by-side comparison:
#* <code>sudo ls -la /proc/$$/ns/net</code> (host's network namespace inode)
#* <code>sudo ls -la /proc/CONTAINER_PID/ns/net</code> (container's network namespace inode)
#* Highlight that the inode numbers are different


=== Exercise C: Interactive Exploration with Fedora ===

'''Objective:''' Run an interactive container with a different Linux distribution (Fedora instead of Ubuntu), demonstrating mount namespace isolation (different root filesystems), PID namespace isolation (isolated process tree), and UTS namespace isolation (different hostname).

'''Important context:''' Your host might be running Ubuntu, but the container will run Fedora. Both will be using the same Linux kernel, but they'll have completely different filesystems and will appear as different "machines" from inside.

'''Step 1: Run Fedora container interactively'''

<syntaxhighlight lang="bash">docker run -it --name fedora-explore fedora bash</syntaxhighlight>
'''Flags explained:'''

* <code>-i</code>: Interactive—keep STDIN open
* <code>-t</code>: Allocate pseudo-TTY (terminal)
* <code>fedora</code>: Pull Fedora base image from Docker Hub
* <code>bash</code>: Command to run inside container (start bash shell)

'''What happens:'''

# Docker downloads Fedora base image (if not cached)
# Creates container from image
# Starts bash inside the container
# Attaches your terminal to that bash session

'''Expected output:'''

<pre>Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
...
Status: Downloaded newer image for fedora:latest
[root@a1b2c3d4e5f6 /]#</pre>
'''Observe the prompt change:'''

* Before: <code>user@hostname:~$</code> (your normal shell)
* After: <code>[root@a1b2c3d4e5f6 /]#</code> (inside container)

You're now '''inside''' the Fedora container!

'''Step 2: Explore the filesystem (Mount Namespace)'''

Check the operating system:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output:'''

<pre>NAME="Fedora Linux"
VERSION="39 (Container Image)"
ID=fedora
VERSION_ID=39
...</pre>
Open a '''new terminal''' on your host (don't close the container terminal) and run:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output on host:'''

<pre>NAME="Ubuntu"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
ID=ubuntu
...</pre>
'''Two different operating systems on the same machine!''' This is mount namespace isolation—the container has its own root filesystem.

'''Back in the container''', explore the filesystem:

<syntaxhighlight lang="bash">ls /</syntaxhighlight>
'''Expected output:'''

<pre>bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var</pre>
These are Fedora's files, not your host's Ubuntu files. They're completely different directory trees.

'''Try to use Ubuntu's package manager:'''

<syntaxhighlight lang="bash">apt update</syntaxhighlight>
'''Expected output:'''

<pre>bash: apt: command not found</pre>
apt doesn't exist in Fedora! Fedora uses a different package manager.

'''Try Fedora's package manager:'''

<syntaxhighlight lang="bash">dnf --version</syntaxhighlight>
'''Expected output:'''

<pre>4.18.2
Installed: dnf-0:4.18.2-1.fc39.noarch
...</pre>
dnf exists because we're in a Fedora environment.

'''Install a package:'''

<syntaxhighlight lang="bash">dnf install -y nano</syntaxhighlight>
This works! We can install packages just like on a real Fedora system.

'''Connection to Lab 2:'''

In Lab 2, you learned about the filesystem hierarchy (<code>/etc</code>, <code>/var</code>, <code>/usr</code>, etc.). Mount namespaces let the container have completely different contents at these paths. The container's <code>/etc</code> is different from the host's <code>/etc</code>.

'''Step 3: Examine process isolation (PID Namespace)'''

Inside the container, check running processes:

<syntaxhighlight lang="bash">ps aux</syntaxhighlight>
'''Expected output:'''

<pre>USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 12345 2345 pts/0 Ss 10:45 0:00 bash
root 67 0.0 0.0 44567 3456 pts/0 R+ 10:47 0:00 ps aux</pre>
'''Only two processes visible!'''

* PID 1: bash (the container's init process)
* PID 67: ps command we just ran

'''On the host''' (in your other terminal):

<syntaxhighlight lang="bash">ps aux | wc -l</syntaxhighlight>
'''Expected output:''' 200+ processes

'''The container cannot see the host's processes!''' This is PID namespace isolation.

'''From the container's perspective, bash is PID 1''' (like systemd is PID 1 on a normal Linux system).

'''From the host's perspective, that same bash process has a different PID''' (e.g., 12345).

'''Connection to Lab 3:'''

In Lab 3, you learned about PIDs and the process hierarchy. PID namespaces create separate process hierarchies—the container has its own process tree starting from PID 1.

'''Step 4: Check hostname (UTS Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>a1b2c3d4e5f6</pre>
This is the container ID (first 12 characters of the full container ID).

'''On the host:'''

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>your-hostname.example.com</pre>
Different hostnames! This is UTS namespace isolation.

'''Step 5: Examine network configuration (Network Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever

17: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever</pre>
'''Analysis:'''

* <code>lo</code>: Container's loopback interface (127.0.0.1)
* <code>eth0@if18</code>: Container's network interface (part of veth pair)
** <code>@if18</code>: Indicates this interface is paired with interface index 18 (on the host)
** IP address: 172.17.0.2 (from docker0 bridge subnet)

'''On the host:'''

<syntaxhighlight lang="bash">ip addr show | grep "172.17"</syntaxhighlight>
You should see the docker0 bridge has IP 172.17.0.1, and you might see veth interfaces for containers.

'''Connection to Lab 7:'''

This is '''exactly''' what you built manually!

* docker0 bridge ≈ br-lab from Lab 7
* Container's eth0 ≈ v-client from Lab 7
* veth pair connects container to bridge ≈ Lab 7's veth pair architecture

'''Step 6: Test internet connectivity from container'''

<syntaxhighlight lang="bash">ping -c 3 8.8.8.8</syntaxhighlight>
'''Expected:''' Ping succeeds!

This works because:

# Container has default route to 172.17.0.1 (docker0 bridge)
# Host has IP forwarding enabled
# Host has NAT rule (MASQUERADE) for 172.17.0.0/16

'''This is identical to what you configured in Lab 7!'''

'''Step 7: Try to see host's processes (will fail)'''

<syntaxhighlight lang="bash">ps aux | grep systemd</syntaxhighlight>
'''Expected:''' No systemd processes visible.

You cannot see the host's processes from inside the container (PID namespace isolation).

'''Step 8: Exit the container'''

<syntaxhighlight lang="bash">exit</syntaxhighlight>
When you exit bash (PID 1 in the container), the container stops automatically.

'''Verify the container stopped:'''

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
a1b2c3d4e5f6 fedora "bash" 5 minutes ago Exited (0) 10 seconds ago fedora-explore</pre>
'''Note:''' The container still exists (STATUS: Exited), but it's not running. You can restart it with <code>docker start fedora-explore</code> if needed.

'''Step 9: Clean up'''

<syntaxhighlight lang="bash">docker rm fedora-explore</syntaxhighlight>

=== Deliverable C ===

Provide screenshots showing:

# '''Inside container''': Output of <code>cat /etc/os-release</code> (showing Fedora)
# '''On host''': Output of <code>cat /etc/os-release</code> (showing Ubuntu or your host OS)
# '''Inside container''': Output of <code>ps aux</code> (showing minimal processes, bash as PID 1)
# '''On host''': Output of <code>ps aux | wc -l</code> (showing many more processes)
# '''Inside container''': Output of <code>hostname</code> (showing container ID)
# '''On host''': Output of <code>hostname</code> (showing host's hostname)
# '''Inside container''': Output of <code>ip addr show</code> (showing eth0 with 172.17.0.x address)
# Brief explanation (4-5 sentences): What do these differences demonstrate about namespace isolation? How does this relate to what you learned in Labs 2, 3, and 7?


=== Exercise D: Persistent Storage with Caddy ===

'''Objective:''' Run Caddy web server with persistent configuration and content using bind mounts, demonstrating that data can survive container removal and be shared between host and container.

Caddy is the web server you've been using throughout Lab 9. We'll run it in a container and configure it using files from the host.


==== Part 1: Basic Caddy Container ====

'''Step 1: Create directory structure on host'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-caddy/{site,data,config}</syntaxhighlight>
'''Directory purposes:'''

* <code>site</code>: Website content (HTML files)
* <code>data</code>: Caddy's data directory (certificates, storage)
* <code>config</code>: Caddy configuration (Caddyfile)

'''Step 2: Create a simple website'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/site/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Docker Caddy Demo</title>
</head>
<body>
<h1>Hello from Dockerized Caddy!</h1>
<div>
This is running in a Docker container.
The file you're viewing is mounted from the host filesystem.
Changes made on the host appear instantly in the container!
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 3: Create Caddyfile configuration'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/config/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Caddyfile explanation:'''

* <code>:80</code>: Listen on port 80 (inside container)
* <code>root * /usr/share/caddy</code>: Serve files from this directory
* <code>file_server</code>: Enable static file serving
* <code>log</code>: Send access logs to stdout (so <code>docker logs</code> can capture them)

'''Step 4: Run Caddy container with volume mounts'''

<syntaxhighlight lang="bash">docker run -d \
--name caddy-persistent \
-p 8080:80 \
-v ~/lab10-caddy/site:/usr/share/caddy \
-v ~/lab10-caddy/data:/data \
-v ~/lab10-caddy/config:/etc/caddy \
caddy</syntaxhighlight>
'''Breaking down the command:'''

* <code>-d</code>: Detached mode (run in background)
* <code>--name caddy-persistent</code>: Give container a memorable name
* <code>-p 8080:80</code>: Port mapping
** Host port 8080 → Container port 80
** This is NAT (DNAT specifically) from Lab 7!
* <code>-v ~/lab10-caddy/site:/usr/share/caddy</code>: Bind mount
** Host directory <code>~/lab10-caddy/site</code> appears at <code>/usr/share/caddy</code> inside container
** Bidirectional: changes on either side are visible on both sides
* <code>-v ~/lab10-caddy/data:/data</code>: Caddy's data storage
* <code>-v ~/lab10-caddy/config:/etc/caddy</code>: Caddy's configuration
* <code>caddy</code>: Image to use

'''Expected output:'''

<pre>Unable to find image 'caddy:latest' locally
latest: Pulling from library/caddy
...
Status: Downloaded newer image for caddy:latest
f8e9c7b6d5a4e3b2c1f7d8a9e6b5c4d3a2f1e8d7c6b5a4e3d2c1b9f8</pre>
'''Step 5: Verify container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f8e9c7b6d5a4 caddy "caddy run..." 10 seconds ago Up 8 seconds 0.0.0.0:8080->80/tcp caddy-persistent</pre>
'''Note the PORTS column:''' <code>0.0.0.0:8080->80/tcp</code>

This means:

* Listen on all host interfaces (<code>0.0.0.0</code>)
* Host port 8080 maps to container port 80
* Protocol: TCP

'''Step 6: Test the web server'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected output:''' Your HTML page!

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
<head>
<title>Docker Caddy Demo</title>
...
<h1>Hello from Dockerized Caddy!</h1>
...
</html></syntaxhighlight>
You can also open <code>http://localhost:8080</code> in a web browser on your host.

'''Step 7: View Caddy logs'''

<syntaxhighlight lang="bash">docker logs caddy-persistent</syntaxhighlight>
'''Expected output:'''

<pre>{"level":"info","ts":1702389123.456,"msg":"using provided configuration",...}
{"level":"info","ts":1702389123.789,"msg":"serving initial configuration"}
...</pre>
These are Caddy's startup logs. When you access the website, you'll see access logs here too.


==== Part 2: Inspect Mounts ====

'''Step 8: Inspect the container's mounts'''

<syntaxhighlight lang="bash">docker inspect caddy-persistent --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">[
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/site",
"Destination": "/usr/share/caddy",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/data",
"Destination": "/data",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/config",
"Destination": "/etc/caddy",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
]</syntaxhighlight>
'''Field explanations:'''

* <code>Type</code>: "bind" (bind mount, not Docker-managed volume)
* <code>Source</code>: Host filesystem path
* <code>Destination</code>: Path inside container
* <code>RW</code>: true (read-write), false would be read-only
* <code>Propagation</code>: How mount events propagate (rprivate = don't propagate to other mounts)

'''Step 9: View from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent df -h | grep caddy</syntaxhighlight>
Shows mounted filesystems inside the container containing "caddy" in the path.

You can also list the files:

<syntaxhighlight lang="bash">docker exec caddy-persistent ls -la /usr/share/caddy</syntaxhighlight>
'''Expected output:'''

<pre>total 12
drwxr-xr-x 2 root root 4096 Dec 12 10:50 .
drwxr-xr-x 1 root root 4096 Dec 12 10:50 ..
-rw-r--r-- 1 root root 687 Dec 12 10:50 index.html</pre>
This is the same <code>index.html</code> you created on the host!


==== Part 3: Test Persistence ====

'''Step 10: Modify the file on the host'''

'''Without stopping the container''', edit the HTML file:

<syntaxhighlight lang="bash">cat >> ~/lab10-caddy/site/index.html << 'EOF'
<div class="info">
🎉 This was added from the host!
The container is still running, and changes appear instantly.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 11: Verify the change appears in the container immediately'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' The new section appears!

You didn't restart the container, yet the content changed. This demonstrates '''bidirectional bind mount synchronization'''.

'''Step 12: Create a new file from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent bash -c "echo '<h2>Created from container</h2>' > /usr/share/caddy/test.html"</syntaxhighlight>
'''Step 13: Verify the file appears on the host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected output:'''

<pre>total 16
drwxr-xr-x 2 youruser youruser 4096 Dec 12 11:00 .
drwxr-xr-x 5 youruser youruser 4096 Dec 12 10:45 ..
-rw-r--r-- 1 youruser youruser 687 Dec 12 10:50 index.html
-rw-r--r-- 1 root root 34 Dec 12 11:00 test.html ← New file!</pre>
The file exists on the host! Changes flow both directions.

'''Note:''' The file is owned by <code>root</code> because the process inside the container runs as root. This is one of the complexities of bind mounts—UID/GID mapping between host and container.

'''Step 14: Stop and remove the container'''

<syntaxhighlight lang="bash">docker stop caddy-persistent
docker rm caddy-persistent</syntaxhighlight>
'''Step 15: Verify files still exist on host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected:''' All files still there!

The files survive because they're stored on the host filesystem, not in the container's ephemeral writable layer.

'''Step 16: Start a NEW container with the same bind mounts'''

<syntaxhighlight lang="bash">docker run -d \
--name caddy-new \
-p 8080:80 \
-v ~/lab10-caddy/site:/usr/share/caddy \
-v ~/lab10-caddy/data:/data \
-v ~/lab10-caddy/config:/etc/caddy \
caddy</syntaxhighlight>
'''Step 17: Verify persistence'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' All your previous content is still there!

The website works immediately because all the content and configuration was stored on the host, not inside the old container.

'''Step 18: Compare to ephemeral storage'''

Let's demonstrate what happens without volumes:

<syntaxhighlight lang="bash"># Start container without volumes
docker run -d --name caddy-temp caddy

# Create file inside container
docker exec caddy-temp bash -c "echo 'temporary' > /tmp/temp.txt"

# Verify file exists
docker exec caddy-temp cat /tmp/temp.txt
# Output: temporary

# Stop and remove container
docker stop caddy-temp
docker rm caddy-temp

# Try to access the file in a new container
docker run -d --name caddy-temp2 caddy
docker exec caddy-temp2 cat /tmp/temp.txt
# Output: cat: /tmp/temp.txt: No such file or directory

# The file is GONE because it was in the ephemeral layer</syntaxhighlight>
'''Step 19: Clean up'''

<syntaxhighlight lang="bash">docker stop caddy-new
docker rm caddy-new</syntaxhighlight>
The files in <code>~/lab10-caddy/</code> remain intact on your host.

<syntaxhighlight lang="bash"># What Docker essentially does:
mount --bind ~/lab10-caddy/site /var/lib/docker/overlay2/.../merged/usr/share/caddy</syntaxhighlight>

=== Deliverable D ===

Provide screenshots showing:

# Output of <code>curl http://localhost:8080</code> showing your custom HTML (initial version)
# Output of <code>docker inspect caddy-persistent --format='{{json .Mounts}}'</code> (formatted with python3 -m json.tool)
# After modifying <code>index.html</code> on the host, output of <code>curl http://localhost:8080</code> showing the new content (without restarting container)
# Output of <code>ls -la ~/lab10-caddy/site/</code> showing both <code>index.html</code> and the <code>test.html</code> created from inside the container
# After removing the original container and starting <code>caddy-new</code>, output of <code>curl http://localhost:8080</code> demonstrating that content persisted


=== Exercise E: Multi-Container Infrastructure with Networking and Resource Limits ===

'''Objective:''' Build a complete three-tier architecture with:

* '''Purple''' container acting as reverse proxy (routes requests based on URL path)
* '''Red''' container serving backend content (memory-limited)
* '''Blue''' container serving backend content (CPU-limited)

This exercise synthesizes everything from Labs 7-9:

* Custom networks (Lab 7 bridges)
* Container-to-container communication (Lab 7 veth pairs and routing)
* Reverse proxy with path-based routing (Lab 9 Caddy configuration)
* Resource limits (cgroups)


==== Part 1: Create a Custom Network ====

'''Step 1: Create a custom bridge network'''

<syntaxhighlight lang="bash">docker network create --subnet=10.10.0.0/24 labnet</syntaxhighlight>
This creates a new bridge (just like <code>br-lab</code> from Lab 7) with subnet 10.10.0.0/24.

'''Expected output:'''

<pre>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2</pre>
This is the network ID.

'''Step 2: Inspect the network'''

<syntaxhighlight lang="bash">docker network inspect labnet</syntaxhighlight>
'''Expected output (abbreviated):'''

<syntaxhighlight lang="json">[
{
"Name": "labnet",
"Id": "a1b2c3d4e5f6...",
"Driver": "bridge",
"IPAM": {
"Config": [
{
"Subnet": "10.10.0.0/24",
"Gateway": "10.10.0.1"
}
]
},
"Containers": {},
...
}
]</syntaxhighlight>
'''Key observations:'''

* <code>Driver: "bridge"</code>: Uses bridge networking (Layer 2 switching)
* <code>Subnet: "10.10.0.0/24"</code>: Our specified subnet
* <code>Gateway: "10.10.0.1"</code>: Docker automatically assigns .1 as gateway
* <code>Containers: {}</code>: No containers connected yet

'''Step 3: Verify bridge creation on host'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
'''Expected output:'''

<pre>5: br-a1b2c3d4e5f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default</pre>
Docker created a new bridge interface! The name includes the network ID prefix.

You can also use:

<syntaxhighlight lang="bash">brctl show</syntaxhighlight>
'''Expected output:'''

<pre>bridge name bridge id STP enabled interfaces
br-a1b2c3d4e5f6 8000.0242a1b2c3d4 no
docker0 8000.0242f7a8b9c0 no</pre>
Two bridges:

* <code>docker0</code>: Default Docker bridge
* <code>br-a1b2c3d4e5f6</code>: Our custom labnet bridge

'''Connection to Lab 7:'''

This is '''exactly''' what you did with:

<syntaxhighlight lang="bash">sudo ip link add br-lab type bridge
sudo ip link set br-lab up
sudo ip addr add 10.0.0.1/24 dev br-lab</syntaxhighlight>
'''Docker automated it!'''


==== Part 2: Create Backend Services (Red and Blue) ====

'''Step 4: Create content directories'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-multicontainer/{red,blue,purple}</syntaxhighlight>
'''Step 5: Create Red service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Red Service</title>
</head>
<body>
<div>
Container: Red
IP: 10.10.0.2
Resource Limit: Memory capped at 256MB
This backend is memory-constrained by cgroups.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 6: Create Red Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Step 7: Create Blue service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Blue Service</title>
</head>
<body>
<h1>Blue Service</h1>
<div class="info">
Container: Blue
IP: 10.10.0.3
Resource Limit: CPU capped at 0.5 cores
This backend is CPU-constrained by cgroups.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 8: Create Blue Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Step 9: Start Red container with memory limit'''

<syntaxhighlight lang="bash">docker run -d \
--name red \
--network labnet \
--ip 10.10.0.2 \
--memory=256m \
--memory-swap=256m \
-v ~/lab10-multicontainer/red:/etc/caddy \
-v ~/lab10-multicontainer/red:/usr/share/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--network labnet</code>: Connect to our custom network (not default docker0)
* <code>--ip 10.10.0.2</code>: Assign static IP address (just like <code>ip addr add</code> in Lab 7!)
* <code>--memory=256m</code>: cgroup memory limit (hard cap: 256MB RAM)
* <code>--memory-swap=256m</code>: Total memory+swap limit (setting equal to memory means no swap)
** If swap was 512m, container could use 256MB RAM + 256MB swap
* <code>-v ~/lab10-multicontainer/red:/etc/caddy</code>: Mount Caddyfile
* <code>-v ~/lab10-multicontainer/red:/usr/share/caddy</code>: Mount website content

'''Expected output:''' Container ID

'''Step 10: Verify Red is running'''

<syntaxhighlight lang="bash">docker ps --filter "name=red"</syntaxhighlight>
'''Step 11: Test Red directly'''

Since Red has IP 10.10.0.2, let's verify we can reach it:

<syntaxhighlight lang="bash"># From host (won't work directly because we're not in labnet)
# But we can use docker exec from another container

# Quick test: use docker exec to reach Red from Red itself
docker exec red curl -s http://localhost | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Red Service</h1></pre>
'''Step 12: Start Blue container with CPU limit'''

<syntaxhighlight lang="bash">docker run -d \
--name blue \
--network labnet \
--ip 10.10.0.3 \
--cpus=0.5 \
-v ~/lab10-multicontainer/blue:/etc/caddy \
-v ~/lab10-multicontainer/blue:/usr/share/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--cpus=0.5</code>: cgroup CPU limit (maximum 50% of one CPU core)
** If CPU-intensive work is attempted, kernel will throttle it
* Other flags same as Red

'''Step 13: Verify both containers are running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 caddy "caddy run..." 20 seconds ago Up 18 seconds 80/tcp red
b7c8d9e0f1a2 caddy "caddy run..." 10 seconds ago Up 8 seconds 80/tcp blue</pre>
'''Step 14: Test container-to-container communication'''

<syntaxhighlight lang="bash"># From Red, ping Blue
docker exec red ping -c 2 10.10.0.3</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># From Red, curl Blue's website
docker exec red curl -s http://10.10.0.3 | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Blue Service</h1></pre>
Containers on the same custom network can communicate directly.


==== Part 3: Create Reverse Proxy (Purple) ====

'''Step 15: Create Purple's Caddyfile'''

This is the crucial piece—routing based on URL path (from Lab 9!)

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/purple/Caddyfile << 'EOF'
:80 {
# Health check endpoint
handle /health {
respond "Purple Reverse Proxy - OK" 200
}

# Root path
handle / {
respond "Purple Reverse Proxy - Use /red/ or /blue/ paths" 200
}

# Route /red/* to red container (strip /red prefix)
handle_path /red/* {
reverse_proxy red:80
}

# Route /blue/* to blue container (strip /blue prefix)
handle_path /blue/* {
reverse_proxy blue:80
}

# Logging
log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Key points:'''

* <code>handle_path /red/*</code>: Matches any path starting with <code>/red/</code>
** <code>handle_path</code> strips the prefix before forwarding
** Client requests <code>/red/index.html</code> → Backend receives <code>/index.html</code>
* <code>reverse_proxy red:80</code>: Forward to container named "red" on port 80
** '''Using hostname "red", not IP!'''
** Docker's embedded DNS resolves "red" to 10.10.0.2
* Same for blue

'''Step 16: Start Purple reverse proxy'''

<syntaxhighlight lang="bash">docker run -d \
--name purple \
--network labnet \
--ip 10.10.0.10 \
-p 8080:80 \
-v ~/lab10-multicontainer/purple:/etc/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--ip 10.10.0.10</code>: Purple gets IP 10.10.0.10 (different from Red/Blue)
* <code>-p 8080:80</code>: '''Port mapping''' (host port 8080 → container port 80)
** This is NAT (DNAT) from Lab 7!
** Traffic to <code>localhost:8080</code> on host gets forwarded to <code>10.10.0.10:80</code> in container


==== Part 4: Testing the Infrastructure ====

'''Step 17: Test health check'''

<syntaxhighlight lang="bash">curl http://localhost:8080/health</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - OK</pre>
This request:

# Reaches host's port 8080
# Docker's DNAT rule forwards to Purple (10.10.0.10:80)
# Purple's Caddy responds directly (no backend needed for /health)

'''Step 18: Test root path'''

<syntaxhighlight lang="bash">curl http://localhost:8080/</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - Use /red/ or /blue/ paths</pre>
'''Step 19: Test routing to Red'''

<syntaxhighlight lang="bash">curl http://localhost:8080/red/</syntaxhighlight>
'''Expected output:''' Red service HTML (with red background styling)

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
...
<h1>Red Service</h1>
<div>
Container: Red
IP: 10.10.0.2
...</syntaxhighlight>
'''What happened:'''

# Your curl → Host port 8080
# DNAT → Purple (10.10.0.10:80)
# Purple sees path <code>/red/</code>, strips <code>/red</code>, forwards <code>/</code> to <code>red:80</code>
# Purple's DNS resolves <code>red</code> to 10.10.0.2
# Request goes to Red (10.10.0.2:80)
# Red's Caddy serves <code>index.html</code>
# Response travels back through Purple to your curl

'''Step 20: Test routing to Blue'''

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/</syntaxhighlight>
'''Expected output:''' Blue service HTML (with blue background styling)

'''Step 21: Test with verbose output to see headers'''

<syntaxhighlight lang="bash">curl -v http://localhost:8080/red/ 2>&1 | grep -A10 "< HTTP"</syntaxhighlight>
'''Expected output:'''

<pre>< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Server: Caddy
< Date: Thu, 12 Dec 2024 11:30:00 GMT
< Content-Length: 687</pre>
'''Observe:''' <code>Server: Caddy</code> header (from Purple, acting as proxy)

'''Step 22: Test in browser'''

Open in your web browser:

* <code>http://localhost:8080/red/</code> → Should see red-styled page
* <code>http://localhost:8080/blue/</code> → Should see blue-styled page


==== Part 5: Inspect Resource Limits ====

'''Step 23: Check Red's memory limit'''

<syntaxhighlight lang="bash">docker inspect red --format='{{.HostConfig.Memory}}'</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
This is 256 MB in bytes (256 × 1024 × 1024 = 268435456).

'''Step 24: Check Blue's CPU limit'''

<syntaxhighlight lang="bash">docker inspect blue --format='{{.HostConfig.NanoCpus}}'</syntaxhighlight>
'''Expected output:'''

<pre>500000000</pre>
This is 0.5 CPU cores in nanocpus (0.5 × 10^9 = 500,000,000).

'''Step 25: View cgroup settings from the host'''

Get Red's main process PID:

<syntaxhighlight lang="bash">RED_PID=$(docker inspect red --format '{{.State.Pid}}')
echo "Red's PID: $RED_PID"</syntaxhighlight>
View memory limit in cgroup filesystem:

<syntaxhighlight lang="bash">cat /sys/fs/cgroup/memory/docker/$RED_PID/memory.limit_in_bytes</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
View Blue's CPU quota:

<syntaxhighlight lang="bash">BLUE_PID=$(docker inspect blue --format '{{.State.Pid}}')
cat /sys/fs/cgroup/cpu/docker/$BLUE_PID/cpu.cfs_quota_us</syntaxhighlight>
'''Expected output:'''

<pre>50000</pre>
'''Explanation:'''

* <code>cpu.cfs_period_us</code>: 100000 (default, 100ms period)
* <code>cpu.cfs_quota_us</code>: 50000 (50ms out of 100ms = 50% = 0.5 CPUs)

'''Connection to kernel concepts:'''

These cgroup files in <code>/sys/fs/cgroup/</code> are how the kernel enforces resource limits. Docker configures these files, and the kernel does the actual enforcement.


==== Part 6: Network Inspection ====

'''Step 26: Inspect labnet network showing all containers'''

<syntaxhighlight lang="bash">docker network inspect labnet --format='{{json .Containers}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">{
"a1b2c3d4e5f6...": {
"Name": "red",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:02",
"IPv4Address": "10.10.0.2/24",
"IPv6Address": ""
},
"b7c8d9e0f1a2...": {
"Name": "blue",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:03",
"IPv4Address": "10.10.0.3/24",
"IPv6Address": ""
},
"f8e9c7b6d5a4...": {
"Name": "purple",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:0a",
"IPv4Address": "10.10.0.10/24",
"IPv6Address": ""
}
}</syntaxhighlight>
All three containers are on the labnet network with their assigned IPs.

'''Step 27: Test DNS resolution between containers'''

<syntaxhighlight lang="bash"># From Purple, resolve "red" hostname
docker exec purple nslookup red</syntaxhighlight>
'''Expected output:'''

<pre>Server: 127.0.0.11
Address: 127.0.0.11#53

Non-authoritative answer:
Name: red
Address: 10.10.0.2</pre>
'''Explanation:'''

* <code>127.0.0.11</code>: Docker's embedded DNS server (listening inside each container)
* DNS resolves container name "red" to IP 10.10.0.2

'''Step 28: Test connectivity using hostnames'''

<syntaxhighlight lang="bash"># Purple pings Red by hostname
docker exec purple ping -c 2 red</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># Purple curls Blue by hostname
docker exec purple curl -s http://blue | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Blue Service</h1></pre>

==== Part 7: Architecture Visualization ====

'''The architecture you built:'''

<pre> ┌─────────────────┐
│ Your Host │
│ (Port 8080) │
└────────┬────────┘
│
Port Mapping (NAT)
8080 → 80
│
┌────────▼────────┐
│ Purple Proxy │
│ 10.10.0.10:80 │
│ (Caddy) │
└────────┬────────┘
│
Docker Network: labnet
(Bridge: br-a1b2c3d4e5f6)
10.10.0.0/24
│
┌─────────┴──────────┐
│ │
┌────────▼────────┐ ┌───────▼─────────┐
│ Red Service │ │ Blue Service │
│ 10.10.0.2:80 │ │ 10.10.0.3:80 │
│ (Caddy) │ │ (Caddy) │
│ [mem: 256MB] │ │ [cpu: 0.5] │
└─────────────────┘ └─────────────────┘</pre>
'''Request flow for <code>curl http://localhost:8080/red/</code>:'''

<pre>1. Curl → localhost:8080 (your host)
2. Host's iptables DNAT rule → 10.10.0.10:80 (Purple)
3. Purple receives request to /red/
4. Purple's Caddy config: handle_path /red/* → reverse_proxy red:80
5. Purple strips /red prefix → request becomes /
6. Purple's DNS resolves "red" → 10.10.0.2
7. Purple → Red (10.10.0.2:80) GET /
8. Red's Caddy serves /usr/share/caddy/index.html
9. Response: Red → Purple → Host → Curl</pre>
'''Compare to Lab 7 and Lab 9:'''

* '''Lab 7''': You manually created bridges, veth pairs, assigned IPs, configured routes, set up NAT
* '''Lab 9''': You manually configured Caddy reverse proxy with path-based routing
* '''This exercise''': Docker automated all the networking, you just specified what you wanted


==== Part 8: Cleanup ====

'''Step 29: Stop all containers'''

<syntaxhighlight lang="bash">docker stop purple red blue</syntaxhighlight>
'''Step 30: Remove containers'''

<syntaxhighlight lang="bash">docker rm purple red blue</syntaxhighlight>
'''Step 31: Remove the network'''

<syntaxhighlight lang="bash">docker network rm labnet</syntaxhighlight>
'''Step 32: Verify cleanup'''

<syntaxhighlight lang="bash">docker ps -a
docker network ls</syntaxhighlight>
Only default networks (bridge, host, none) should remain.

'''Step 33: Verify host bridge removed'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
The custom bridge (br-a1b2c3d4e5f6) should be gone. Only docker0 remains.


=== Deliverable E ===

Provide screenshots showing:

# Output of <code>docker network inspect labnet</code> showing all three containers with their IPs (before running curl tests)
# Output of <code>curl http://localhost:8080/health</code> (health check response)
# Output of <code>curl http://localhost:8080/red/</code> (Red service HTML) with visible red-styled content
# Output of <code>curl http://localhost:8080/blue/</code> (Blue service HTML) with visible blue-styled content
# Output of <code>docker inspect red --format='{{.HostConfig.Memory}}'</code> showing memory limit in bytes
# Output of <code>docker inspect blue --format='{{.HostConfig.NanoCpus}}'</code> showing CPU limit in nanocpus
# Output of <code>docker exec purple nslookup red</code> showing DNS resolution


== Reference: Docker Command Quick Guide ==

This section provides a quick reference for Docker commands introduced in this lab.


=== Container Lifecycle ===

<syntaxhighlight lang="bash"># Run container (create + start)
docker run [OPTIONS] IMAGE [COMMAND]
docker run -d nginx # Detached (background)
docker run -it ubuntu bash # Interactive with terminal
docker run --name mycontainer nginx # Assign name

# List containers
docker ps # Running only
docker ps -a # All (including stopped)
docker ps -q # Show only IDs (quiet)

# Start stopped container
docker start CONTAINER

# Stop running container
docker stop CONTAINER # Graceful (SIGTERM)
docker kill CONTAINER # Forceful (SIGKILL)

# Restart container
docker restart CONTAINER

# Remove container
docker rm CONTAINER # Must be stopped first
docker rm -f CONTAINER # Force remove (stop + remove)

# Execute command in running container
docker exec CONTAINER COMMAND
docker exec -it CONTAINER bash # Interactive shell

# View container logs
docker logs CONTAINER
docker logs -f CONTAINER # Follow (tail -f style)

# Inspect container (detailed JSON info)
docker inspect CONTAINER
docker inspect CONTAINER --format='{{.State.Status}}'</syntaxhighlight>

=== Image Management ===

<syntaxhighlight lang="bash"># List images
docker images
docker image ls

# Pull image from registry
docker pull IMAGE[:TAG]
docker pull nginx # Latest tag (default)
docker pull nginx:1.21 # Specific tag

# Remove image
docker rmi IMAGE
docker image rm IMAGE

# View image layers
docker history IMAGE

# Remove unused images
docker image prune # Dangling images
docker image prune -a # All unused images</syntaxhighlight>

=== Network Management ===

<syntaxhighlight lang="bash"># List networks
docker network ls

# Create network
docker network create NETWORK
docker network create --subnet=10.20.0.0/24 mynet

# Inspect network
docker network inspect NETWORK

# Connect container to network
docker network connect NETWORK CONTAINER

# Disconnect container from network
docker network disconnect NETWORK CONTAINER

# Remove network
docker network rm NETWORK

# Remove unused networks
docker network prune</syntaxhighlight>

=== Volume Management ===

<syntaxhighlight lang="bash"># List volumes
docker volume ls

# Create volume
docker volume create VOLUME

# Inspect volume
docker volume inspect VOLUME

# Remove volume
docker volume rm VOLUME

# Remove unused volumes
docker volume prune</syntaxhighlight>

=== Resource Management ===

<syntaxhighlight lang="bash"># CPU limits
--cpus=1.5 # Limit to 1.5 CPU cores
--cpu-shares=512 # Relative priority (default 1024)
--cpuset-cpus=0,1 # Pin to specific cores

# Memory limits
--memory=512m # Hard limit: 512 MB RAM
--memory=2g # Hard limit: 2 GB RAM
--memory-swap=1g # Total memory+swap
--memory-reservation=256m # Soft limit

# I/O limits
--device-read-bps=/dev/sda:10mb # Limit read bandwidth
--device-write-bps=/dev/sda:10mb # Limit write bandwidth

# Process limits
--pids-limit=100 # Max 100 processes</syntaxhighlight>

=== Inspection and Debugging ===

<syntaxhighlight lang="bash"># View resource usage stats
docker stats
docker stats CONTAINER # Specific container

# View processes in container
docker top CONTAINER

# View port mappings
docker port CONTAINER

# Copy files between host and container
docker cp CONTAINER:/path/to/file ./file # Container → Host
docker cp ./file CONTAINER:/path/to/file # Host → Container

# Stream events from Docker daemon
docker events

# Show disk usage
docker system df

# System-wide cleanup
docker system prune # Remove unused objects
docker system prune -a # Remove all unused objects
docker system prune -a --volumes # Include volumes</syntaxhighlight>

== Common Troubleshooting ==


=== Installation Issues ===

'''Problem:''' <code>docker --version</code> fails after installation

'''Solution:'''

<syntaxhighlight lang="bash"># Check if Docker daemon is running
sudo systemctl status docker

# If not running, start it
sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
'''Problem:''' "Cannot connect to the Docker daemon"

'''Cause:''' Docker daemon not running or permission issue

'''Solution:'''

<syntaxhighlight lang="bash"># Check daemon status
sudo systemctl status docker

# Check if your user is in docker group
groups | grep docker

# If not, add user and log out/in
sudo usermod -aG docker $USER</syntaxhighlight>

=== Permission Issues ===

'''Problem:''' "permission denied" when running docker commands

'''Solution:'''

<syntaxhighlight lang="bash"># Option 1: Add user to docker group (permanent)
sudo usermod -aG docker $USER
# Then log out and log back in

# Option 2: Use sudo (temporary)
sudo docker run hello-world</syntaxhighlight>
'''Problem:''' Files created by container are owned by root

'''Cause:''' Container runs as root (UID 0) by default

'''Solution:'''

<syntaxhighlight lang="bash"># Run container as specific user
docker run --user $(id -u):$(id -g) IMAGE

# Or use user namespaces (advanced)</syntaxhighlight>

=== Network Issues ===

'''Problem:''' Container can't access internet

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Test from container
docker exec CONTAINER ping -c 2 8.8.8.8

# Check Docker's NAT rules
sudo iptables -t nat -L -n | grep docker

# Check IP forwarding
sysctl net.ipv4.ip_forward</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Enable IP forwarding if disabled
sudo sysctl -w net.ipv4.ip_forward=1

# Restart Docker daemon
sudo systemctl restart docker</syntaxhighlight>
'''Problem:''' Containers on custom network can't communicate

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check network exists
docker network ls

# Check containers are on same network
docker network inspect NETWORK

# Test connectivity
docker exec CONTAINER1 ping CONTAINER2_IP</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Ensure both containers on same network
docker network connect NETWORK CONTAINER</syntaxhighlight>
'''Problem:''' Port mapping not working (<code>-p</code> flag)

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check port is actually mapped
docker port CONTAINER

# Check if host port is already in use
sudo ss -tulpn | grep :8080</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># If port in use, use different host port
docker run -p 8081:80 nginx

# Or stop the conflicting process
sudo fuser -k 8080/tcp</syntaxhighlight>

=== Storage Issues ===

'''Problem:''' "No space left on device"

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check Docker disk usage
docker system df

# Check host disk space
df -h /var/lib/docker</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Remove unused objects
docker system prune -a

# Remove specific old images
docker images
docker rmi IMAGE_ID</syntaxhighlight>
'''Problem:''' Changes in bind mount not visible in container

'''Cause:''' Path doesn't exist or wrong path specified

'''Solution:'''

<syntaxhighlight lang="bash"># Verify path exists on host
ls -la /path/to/host/directory

# Use absolute paths
docker run -v /absolute/path:/container/path IMAGE

# Or use $PWD for current directory
docker run -v $PWD/relative/path:/container/path IMAGE</syntaxhighlight>

=== Resource Limit Issues ===

'''Problem:''' Container killed unexpectedly

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check container exit code
docker inspect CONTAINER --format='{{.State.ExitCode}}'
# Exit code 137 = killed (often OOM)

# Check logs
docker logs CONTAINER</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Increase memory limit
docker run --memory=1g IMAGE

# Or run without memory limit (default)
docker run IMAGE</syntaxhighlight>
'''Problem:''' Container using too much CPU

'''Solution:'''

<syntaxhighlight lang="bash"># Limit CPU usage
docker run --cpus=0.5 IMAGE

# Check what's consuming CPU
docker exec CONTAINER top</syntaxhighlight>

== Next Steps: Dockerfile and Docker Compose ==

Congratulations! You've mastered the fundamental OS concepts behind containers:

* '''Namespaces''' provide isolation (network, PID, mount, UTS, IPC, user, cgroup)
* '''cgroups''' enforce resource limits (CPU, memory, I/O)
* '''OverlayFS''' provides efficient layered filesystems
* '''Bridges and veth pairs''' connect containers (same as Lab 7!)
* '''Volumes''' persist data beyond container lifecycles

However, you've been using '''pre-built images''' and running containers with long <code>docker run</code> commands. In production environments, you need:

# '''Custom images''' tailored to your applications
# '''Reproducible builds''' that can be version-controlled
# '''Multi-container orchestration''' with coordinated startup and networking

This is where '''Dockerfile''' and '''Docker Compose''' come in.


=== Dockerfile: Building Custom Images ===

Instead of starting from a base image and manually installing packages, you define your application's environment in a <code>Dockerfile</code>:

<syntaxhighlight lang="dockerfile"># Start from Ubuntu base image
FROM ubuntu:22.04

# Install dependencies
RUN apt-get update && apt-get install -y \
python3 \
python3-pip \
&& rm -rf /var/lib/apt/lists/*

# Copy application code
COPY app.py /app/
COPY requirements.txt /app/

# Install Python dependencies
WORKDIR /app
RUN pip3 install -r requirements.txt

# Expose port
EXPOSE 8000

# Define startup command
CMD ["python3", "app.py"]</syntaxhighlight>
'''Build the image:'''

<syntaxhighlight lang="bash">docker build -t myapp:1.0 .</syntaxhighlight>
'''Run containers from your custom image:'''

<syntaxhighlight lang="bash">docker run -d -p 8000:8000 myapp:1.0</syntaxhighlight>
'''Benefits:'''

* '''Reproducibility''': Same Dockerfile always builds identical image
* '''Version control''': Dockerfile lives in git alongside code
* '''Documentation''': Dockerfile explicitly documents dependencies and setup
* '''Automation''': CI/CD pipelines can build images automatically

'''Common Dockerfile instructions:'''

* <code>FROM</code>: Base image to start from
* <code>RUN</code>: Execute command during build (install packages, etc.)
* <code>COPY</code> / <code>ADD</code>: Copy files from host into image
* <code>WORKDIR</code>: Set working directory
* <code>ENV</code>: Set environment variables
* <code>EXPOSE</code>: Document which ports the application uses
* <code>CMD</code>: Default command to run when container starts
* <code>ENTRYPOINT</code>: Configure container as executable

'''Best practices:'''

* Use specific image tags (not <code>latest</code>)
* Minimize layers (combine <code>RUN</code> commands)
* Leverage build cache (order instructions from least to most frequently changing)
* Use <code>.dockerignore</code> (like <code>.gitignore</code> for Docker builds)
* Don't run as root (use <code>USER</code> instruction)
* Multi-stage builds for smaller images


=== Docker Compose: Multi-Container Orchestration ===

Instead of running multiple <code>docker run</code> commands with complex options, define your entire infrastructure in a <code>docker-compose.yml</code> file:

<syntaxhighlight lang="yaml">version: '3.8'

services:
# Purple reverse proxy
purple:
image: caddy
ports:
- "8080:80"
volumes:
- ./purple:/etc/caddy
networks:
labnet:
ipv4_address: 10.10.0.10
depends_on:
- red
- blue

# Red backend
red:
image: caddy
volumes:
- ./red:/etc/caddy
- ./red:/usr/share/caddy
networks:
labnet:
ipv4_address: 10.10.0.2
deploy:
resources:
limits:
memory: 256M

# Blue backend
blue:
image: caddy
volumes:
- ./blue:/etc/caddy
- ./blue:/usr/share/caddy
networks:
labnet:
ipv4_address: 10.10.0.3
deploy:
resources:
limits:
cpus: '0.5'

networks:
labnet:
driver: bridge
ipam:
config:
- subnet: 10.10.0.0/24</syntaxhighlight>
'''Start entire infrastructure:'''

<syntaxhighlight lang="bash">docker compose up</syntaxhighlight>
Or in detached mode:

<syntaxhighlight lang="bash">docker compose up -d</syntaxhighlight>
'''Stop everything:'''

<syntaxhighlight lang="bash">docker compose down</syntaxhighlight>
'''View logs:'''

<syntaxhighlight lang="bash">docker compose logs -f</syntaxhighlight>
'''Benefits:'''

* '''Declarative''': Describe desired state, not imperative commands
* '''Single source of truth''': One file defines entire application
* '''Easy to share''': Colleagues can run <code>docker compose up</code> and get identical environment
* '''Development/production parity''': Same compose file works everywhere
* '''Automatic networking''': Compose creates network and DNS automatically

'''This is the production-ready way to deploy multi-container applications.'''

'''Further learning:'''

* '''Dockerfile''': Learn advanced instructions, multi-stage builds, build arguments
* '''Docker Compose''': Learn service dependencies, health checks, scaling
* '''Docker Swarm''': Docker's built-in orchestration for multi-host deployments
* '''Kubernetes''': Industry-standard container orchestration platform
* '''Container registries''': Push images to Docker Hub, GitHub Container Registry, or private registries
* '''Security''': Image scanning, rootless Docker, seccomp profiles, AppArmor

These topics build on the solid foundation you've established in this lab. You now understand what containers actually are at the OS level—the rest is learning tools that make containers easier to build and deploy.


== Deliverables and Assessment ==

Submit a single PDF document containing all deliverables from Exercises A through E, organized with clear section headers matching the exercise labels.

'''Required deliverables:'''

* '''Deliverable A''': Installation verification (screenshots)
* '''Deliverable B''': Hello World and namespace inspection (screenshots)
* '''Deliverable C''': Fedora exploration (screenshots)
* '''Deliverable D''': Persistent storage (screenshots)
* '''Deliverable E''': Multi-container infrastructure (screenshots)


== Additional Resources ==

This lab introduced containerization using Docker, demonstrating how Linux kernel features (namespaces, cgroups, OverlayFS) are composed to create isolated application environments. You've seen that Docker is not magic—it's sophisticated automation of kernel primitives you already understand from previous labs.


=== For Further Study ===

'''Container Internals:'''

* Deep dive into runc (the OCI runtime that Docker uses)
* Understanding containerd (container runtime layer)
* Linux capabilities and security contexts
* AppArmor and SELinux profiles for containers
* User namespaces and rootless containers
* Seccomp profiles for system call filtering

'''Dockerfile Best Practices:'''

* Multi-stage builds for smaller images
* Build cache optimization strategies
* Layer ordering for efficient rebuilds
* .dockerignore for excluding files
* Security scanning with Trivy or Clair
* Distroless and minimal base images

'''Docker Compose Advanced:'''

* Service dependencies with health checks
* Environment-specific overrides
* Secrets management
* Multiple compose files (base + overrides)
* Named volumes vs bind mounts
* Integration testing with compose

'''Container Orchestration:'''

* Kubernetes architecture and concepts
* kubectl basics
* Pods, Services, Deployments, ConfigMaps
* Kubernetes networking (CNI plugins)
* Helm charts for package management
* Service mesh (Istio, Linkerd)

'''Container Networking Deep Dive:'''

* Bridge vs host vs macvlan networking
* Overlay networks for multi-host communication
* Network plugins and CNI specification
* Load balancing strategies
* Service discovery patterns
* Network policies and segmentation

'''Security:'''

* Container escape techniques and mitigations
* Image vulnerability scanning
* Runtime security monitoring (Falco)
* Least privilege principles
* Supply chain security
* Harbor for secure image registry

'''Performance:'''

* Container resource tuning
* Storage drivers (overlay2, btrfs, zfs)
* Network performance optimization
* Monitoring with Prometheus and Grafana
* Distributed tracing with Jaeger

'''Production Operations:'''

* Logging strategies (centralized logging)
* Health checks and readiness probes
* Rolling updates and blue-green deployments
* Backup and disaster recovery
* CI/CD integration (Jenkins, GitLab CI)
* Container registries (private, public)


=== Relevant Manual Pages ===

<syntaxhighlight lang="bash">man 7 namespaces # Linux namespaces overview
man 7 cgroups # Control groups overview
man 2 unshare # Create namespaces
man 2 setns # Enter existing namespace
man 8 nsenter # Run program in namespace
man 1 docker # Docker CLI reference
man 1 docker-run # docker run reference
man 1 docker-compose # Docker Compose reference</syntaxhighlight>

=== Online Resources ===

'''Official Documentation:'''

* [https://docs.docker.com/ Docker Documentation] - Comprehensive official docs
* [https://hub.docker.com/ Docker Hub] - Public image registry
* [https://opencontainers.org/ OCI Specification] - Open Container Initiative standards
* [https://containerd.io/docs/ containerd Documentation] - Container runtime

'''Tutorials and Guides:'''

* [https://docker-curriculum.com/ Docker Curriculum] - Beginner-friendly tutorial
* [https://labs.play-with-docker.com/ Play with Docker] - Free interactive playground
* [https://kubernetes.io/docs/ Kubernetes Documentation] - K8s official docs
* [https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ Dockerfile Best Practices]

'''Deep Dives:'''

* [https://lwn.net/Articles/531114/ Understanding Namespaces (LWN)] - Series on Linux namespaces
* [https://jvns.ca/blog/2016/10/10/what-even-is-a-container/ How Containers Work] - Excellent blog post by Julia Evans
* [https://sysdig.com/blog/dockerfile-best-practices/ Container Security Best Practices] - Security-focused guide

'''Community:'''

* [https://forums.docker.com/ Docker Forums] - Community support
* [https://stackoverflow.com/questions/tagged/docker Stack Overflow - Docker Tag]
* [https://reddit.com/r/docker Reddit r/docker]
* [https://slack.cncf.io/ CNCF Slack] - Cloud Native Computing Foundation community

'''Practice Environments:'''

* [https://www.katacoda.com/ Katacoda] - Interactive Docker and Kubernetes scenarios
* [https://labs.play-with-k8s.com/ Play with Kubernetes] - K8s playground
* [https://killercoda.com/ KillerCoda] - Interactive learning scenarios

OS Lab 10 - Containers and Docker

2025-12-12T14:52:44Z

Vserbu: Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Explain how containers use Linux kernel namespaces (PID, mount, network, UTS, I...

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how containers use Linux kernel namespaces (PID, mount, network, UTS, IPC, user, cgroup) to provide process isolation without requiring separate operating systems or hypervisors.
* Differentiate between container images (immutable filesystem templates) and running containers (ephemeral process instances in isolated namespaces).
* Understand how OverlayFS provides efficient layered filesystems that allow multiple containers to share common base layers while maintaining separate writable layers.
* Apply cgroup resource limits to constrain container CPU, memory, and I/O usage, preventing resource monopolization.
* Configure Docker networking using custom bridges, port mapping (NAT), and container-to-container communication with automatic DNS resolution.
* Use volumes and bind mounts to persist data beyond container lifecycles and share data between containers and the host.
* Build multi-container applications with coordinated networking and resource management, demonstrating modern microservices architecture patterns.
* Connect container concepts to previous labs: relate network namespaces to Lab 7, mount namespaces to Lab 2, PID namespaces to Lab 3, and Docker networking to Labs 7-9.


== Introduction ==


=== From Manual Isolation to Automated Containers ===

In Labs 7-9, you manually constructed network isolation using Linux kernel primitives. You created virtual network interfaces with <code>ip link add type veth</code>, configured bridges with <code>ip link add type bridge</code>, established isolated network stacks with <code>ip netns add</code>, and set up routing and NAT rules. Through this hands-on work, you gained deep insight into how the Linux kernel provides network isolation at the namespace level.

Every time you executed <code>sudo ip netns exec red ping 10.0.0.3</code>, you were demonstrating a fundamental concept: the kernel can create completely isolated environments where processes see only a subset of system resources. The <code>red</code> namespace had its own network interfaces, its own routing table, and its own firewall rules—completely invisible to processes running in other namespaces or on the host.

This isolation is powerful, but network namespaces are just one of seven namespace types that the Linux kernel provides. To fully isolate an application and create what we call a "container," you need:

* '''Network namespace''' (<code>net</code>): Isolated network stack—you've mastered this in Labs 7-9
* '''PID namespace''' (<code>pid</code>): Isolated process tree—each namespace has its own PID 1
* '''Mount namespace''' (<code>mnt</code>): Isolated filesystem view—different root directory from the host
* '''UTS namespace''' (<code>uts</code>): Isolated hostname—each container can have its own hostname
* '''IPC namespace''' (<code>ipc</code>): Isolated inter-process communication—shared memory, semaphores, message queues
* '''User namespace''' (<code>user</code>): Isolated UIDs/GIDs—security boundary for privilege separation
* '''Cgroup namespace''' (<code>cgroup</code>): Isolated view of control group hierarchy

Additionally, you need:

* '''Control groups (cgroups)''' to limit CPU, memory, and I/O resources
* '''Copy-on-write filesystems''' (OverlayFS) for efficient storage
* '''Image management''' for distributing application packages
* '''Orchestration''' for managing the lifecycle of multiple isolated environments

Manually setting up all of these components for every application would require hundreds of commands and deep kernel knowledge. This is the problem that containerization technology solves.


=== What are Containers? ===

A '''container''' is an isolated process (or process tree) that uses Linux kernel features—namespaces, cgroups, and layered filesystems—to provide the illusion of running in a separate system. Containers package an application with its dependencies, libraries, and configuration into a single unit that can run consistently across different environments.

Containers are not a specific product or tool—they are a pattern for using kernel isolation features. Multiple container runtimes exist, each implementing this pattern:

'''Container Runtimes:'''

* '''Docker''': The most widely adopted container platform, providing a complete ecosystem (daemon, CLI, image format, registry)
* '''Podman''': Daemonless container engine, compatible with Docker images and commands, can run rootless
* '''containerd''': Industry-standard container runtime, used by Kubernetes and Docker (as of Docker 1.11+)
* '''CRI-O''': Lightweight container runtime built for Kubernetes, implementing the Container Runtime Interface (CRI)
* '''LXC/LXD''': System containers that more closely resemble traditional VMs, providing full init systems

'''What Container Runtimes Provide:'''

# '''Namespace Management''': Automatically create and configure all necessary namespace types
# '''Filesystem Layers''': Use OverlayFS or similar copy-on-write filesystems for efficient storage
# '''Network Configuration''': Set up bridges, veth pairs, and NAT rules automatically
# '''Resource Control''': Configure cgroups to enforce CPU and memory limits
# '''Image Distribution''': Provide standard formats (OCI) for packaging and distributing applications
# '''Lifecycle Management''': Offer commands to create, start, stop, and remove containers


=== Docker as a Container Runtime ===

In this lab, we use '''Docker''' because it is the most widely deployed and well-documented container runtime. Docker's architecture consists of:

* '''Docker Engine (dockerd)''': Daemon that manages containers
* '''Docker CLI (docker)''': Command-line interface for interacting with the daemon
* '''containerd''': Lower-level runtime that Docker uses internally
* '''runc''': OCI-compliant runtime that actually creates and runs containers

When you execute <code>docker run nginx</code>, Docker performs approximately 50-100 system calls to configure namespaces, mount filesystems, set up networking, and start the process—all operations you could do manually but would require significant time and expertise.

The concepts you learn with Docker apply to all container runtimes, as they all use the same underlying kernel features. The commands may differ (e.g., <code>podman run</code> instead of <code>docker run</code>), but the fundamental mechanisms remain the same.


=== The Shift in Software Deployment ===

Containers represent a fundamental paradigm shift in how we think about software deployment and infrastructure management.

'''Traditional Deployment Model (Pre-Container Era):'''

<pre>1. Provision a server (physical or virtual machine)
2. Install operating system (Ubuntu, RHEL, etc.)
3. Install runtime dependencies (Python 3.9, Node.js 16, specific library versions)
4. Configure environment variables, users, permissions
5. Deploy application code
6. Configure monitoring, logging, security
7. Hope everything works the same as on your development machine
8. Troubleshoot when it doesn't ("works on my machine" problem)</pre>
This model suffers from several critical issues:

* '''Dependency Hell''': Different applications require different, potentially conflicting library versions
* '''Configuration Drift''': Development, staging, and production environments gradually diverge
* '''Snowflake Servers''': Each server becomes unique and unreproducible
* '''Slow Deployment''': Setting up a new environment can take hours or days
* '''Poor Resource Utilization''': Applications can't share servers due to dependency conflicts

'''Container-Based Deployment Model:'''

<pre>1. Developer creates Dockerfile specifying exact environment
2. Build process creates immutable container image with all dependencies
3. Image tested in CI/CD pipeline (identical to production)
4. Image deployed to any server with Docker installed
5. Container starts in seconds with guaranteed-identical environment
6. Multiple isolated applications run on same host without conflicts</pre>
This model provides:

* '''Immutable Infrastructure''': Images never change after building; deploy new versions rather than modifying running systems
* '''Reproducibility''': Development environment = testing environment = production environment
* '''Portability''': "Build once, run anywhere" (laptop, data center, cloud)
* '''Efficiency''': Run 10-100 containers on a single host (vs. 5-10 VMs)
* '''Rapid Deployment''': Start containers in milliseconds vs. minutes for VMs
* '''Microservices Architecture''': Enables decomposing monoliths into independently deployable services

This shift has revolutionized software engineering, enabling modern DevOps practices, continuous deployment, and cloud-native architectures. Companies like Netflix, Uber, and Airbnb run millions of containers to serve billions of requests daily.


=== Containers vs Virtual Machines ===

Understanding the architectural difference between containers and virtual machines is crucial for appreciating why containers have become the dominant deployment model.

'''Virtual Machine Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Libraries │ │ Libraries │ │ Libraries │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Guest OS │ │ Guest OS │ │ Guest OS │
│ (Kernel) │ │ (Kernel) │ │ (Kernel) │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
Hypervisor (VMware, KVM, Xen)
─────────────────────────────────────────────────
Host Operating System & Kernel
─────────────────────────────────────────────────
Hardware</pre>
'''Characteristics:'''

* Each VM runs a complete guest operating system with its own kernel
* Hypervisor emulates hardware, providing virtual CPUs, RAM, disks, NICs
* Strong isolation (separate kernels mean vulnerabilities in one VM don't affect others)
* Heavy resource consumption (each OS kernel needs 1-2GB RAM)
* Slow startup (boot entire OS: 30-60 seconds)
* Large disk footprint (each VM stores complete OS: 1-10GB)

'''Container Architecture:'''

<pre>┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ App A │ │ App B │ │ App C │
├─────────────┤ ├─────────────┤ ├─────────────┤
│ Libraries │ │ Libraries │ │ Libraries │
└─────────────┘ └─────────────┘ └─────────────┘
─────────────────────────────────────────────────
Container Runtime (Docker Engine)
─────────────────────────────────────────────────
Host Operating System & Shared Kernel
─────────────────────────────────────────────────
Hardware</pre>
'''Characteristics:'''

* All containers share the host's kernel (no guest OS needed)
* Container runtime manages namespace and cgroup isolation
* Lightweight isolation (namespaces separate processes, but they're still just processes)
* Minimal resource overhead (containers use only incremental memory beyond their application)
* Fast startup (start process in isolated namespace: milliseconds)
* Small disk footprint (layered filesystem shares common base images: 10-100MB incremental)

'''The Trade-off:'''

Virtual machines provide '''stronger security isolation''' at the cost of '''resource efficiency'''. If your threat model requires complete kernel isolation (e.g., multi-tenant cloud providers hosting untrusted code), VMs are appropriate.

Containers provide '''lighter-weight isolation''' with '''much better resource efficiency'''. If you're running your own applications on your own infrastructure, containers are usually the right choice. You can run 10-100 containers on hardware that would support only 5-10 VMs.

'''An Important Insight:''' When you run <code>ps aux</code> on the host, you see container processes. They're not hidden inside separate kernels like VM processes would be. This demonstrates that containers are just isolated processes on the host—the kernel makes them appear isolated through namespaces, but they're fundamentally just processes.

This is both a feature (efficiency, observability) and a constraint (shared kernel means a kernel vulnerability could affect all containers). Modern container security practices use defense-in-depth: namespaces + cgroups + seccomp + AppArmor/SELinux + user namespaces to create multiple security layers.


== Prerequisites ==


=== System Requirements ===

* '''Operating System''': Linux-based system (Ubuntu 20.04+ recommended, but Debian, Fedora, CentOS also supported)
* '''RAM''': Minimum 2GB, 4GB recommended for comfortable operation
* '''Disk Space''': At least 20GB free (Docker images and container layers consume significant space)
* '''CPU''': Any modern x86_64 or ARM64 processor
* '''Privileges''': Root access via <code>sudo</code> (required for Docker installation and initial setup)
* '''Kernel''': Minimum Linux kernel 3.10 (kernel 4.0+ recommended for full feature support)

'''Check your kernel version:'''

<syntaxhighlight lang="bash">uname -r</syntaxhighlight>
If below 3.10, you'll need to update your kernel before proceeding.

'''Check available disk space:'''

<syntaxhighlight lang="bash">df -h /var/lib/docker</syntaxhighlight>
Docker stores images and containers in <code>/var/lib/docker</code> by default. Ensure you have sufficient space.


=== Required Packages ===

Before beginning, ensure the following packages are installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg \
lsb-release \
bridge-utils \
net-tools</syntaxhighlight>
'''Package descriptions:'''

* <code>apt-transport-https</code>: Enables apt to retrieve packages over HTTPS
* <code>ca-certificates</code>: Common CA certificates for SSL verification
* <code>curl</code>: Command-line tool for transferring data (used to download Docker's GPG key)
* <code>gnupg</code>: GNU Privacy Guard for verifying package signatures
* <code>lsb-release</code>: Provides Linux Standard Base version information (used to detect Ubuntu version)
* <code>bridge-utils</code>: Tools for managing bridge devices (<code>brctl</code> command)
* <code>net-tools</code>: Legacy networking tools (<code>ifconfig</code>, <code>netstat</code>) for compatibility


=== Knowledge Prerequisites ===

This lab builds directly on concepts from previous labs. You should be comfortable with:

'''From Lab 2 (Filesystems):'''

* Filesystem hierarchy and directory structure
* Mount points and the <code>mount</code> command
* Understanding of <code>/</code>, <code>/etc</code>, <code>/var</code>, <code>/usr</code> purposes
* File permissions and ownership (<code>chmod</code>, <code>chown</code>)
* Symbolic links and filesystem navigation

'''From Lab 3 (Processes and Jobs):'''

* Process IDs (PIDs) and process hierarchy
* Parent-child process relationships
* <code>ps aux</code> command and process listing
* Foreground vs. background processes
* Process signals (SIGTERM, SIGKILL)

'''From Lab 4 (Users, Groups, and Permissions):'''

* User IDs (UIDs) and group IDs (GIDs)
* Root vs. unprivileged users
* <code>sudo</code> for privilege escalation
* File and directory permissions (read, write, execute)
* Security implications of running processes as root

'''From Lab 7 (Network Fundamentals):'''

* Network interfaces and IP addresses
* Bridges and virtual ethernet (veth) pairs
* Subnets and CIDR notation
* Routing tables and default gateways
* Network Address Translation (NAT)
* '''Network namespaces''' (<code>ip netns add</code>, <code>ip netns exec</code>)

This is crucial—Docker networking uses the exact same mechanisms you built manually.

'''From Lab 8 (Transport and Security):'''

* TCP and UDP protocols
* Port numbers and socket addresses (IP:PORT)
* Client-server communication model
* The concept of listening vs. connecting
* TLS/SSL (Docker can use HTTPS for secure image distribution)

'''From Lab 9 (Application Protocols):'''

* HTTP/HTTPS protocols
* Reverse proxies and path-based routing
* DNS and hostname resolution
* Caddy web server configuration
* Multi-tier application architecture

You should also be comfortable with:

* Command-line text manipulation (<code>grep</code>, <code>awk</code>, <code>cut</code>, <code>sed</code>)
* Basic bash scripting (variables, loops, conditionals)
* Using multiple terminal windows simultaneously


== Theoretical Background ==


=== Linux Namespaces: The Foundation of Containers ===

In Labs 7-9, you worked extensively with network namespaces—one of seven namespace types provided by the Linux kernel. Every time you executed:

<syntaxhighlight lang="bash">sudo ip netns add red
sudo ip netns exec red ip addr show</syntaxhighlight>
You were creating an isolated network environment and executing commands within that isolated environment. The processes running in the <code>red</code> namespace could not see network interfaces, routes, or connections in other namespaces. This isolation is the fundamental mechanism that makes containers possible.

Docker extends this concept to six additional namespace types, providing complete process isolation. Understanding namespaces is essential to understanding containers—they are not optional background knowledge, but rather the core technology that defines what a container is.


==== The Seven Namespace Types ====

'''1. Network Namespace (<code>net</code>)'''

You know this namespace intimately from Labs 7-9. When you created the <code>red</code> and <code>blue</code> namespaces, you were creating isolated network stacks.

'''What it isolates:'''

* Network interfaces (lo, eth0, wlan0, etc.)
* IP addresses (each namespace has its own IPs)
* Routing tables (<code>ip route show</code> output differs per namespace)
* Firewall rules (iptables/nftables rules are namespace-specific)
* Network sockets and ports (multiple processes in different namespaces can bind to the same port number)

'''Connection to Lab 7:'''

In Lab 7, you manually created network namespaces:

<syntaxhighlight lang="bash">sudo ip netns add red # Create isolated network stack
sudo ip netns exec red ip link show # View interfaces in that namespace</syntaxhighlight>
Docker does exactly this when you run a container, but also creates six other namespace types simultaneously.

'''Example implications:'''

* Container A can listen on port 80, Container B can listen on port 80—no conflict
* Container A cannot see Container B's network connections (<code>ss -tuna</code> shows only its own)
* Each container has its own localhost (127.0.0.1) that's separate from the host

'''2. PID Namespace (<code>pid</code>)'''

The PID namespace isolates the process ID number space. This is related to what you learned in Lab 3 about process management.

'''What it isolates:'''

* Process IDs—processes in different PID namespaces can have the same PID
* Process visibility—processes can only see other processes in the same PID namespace
* PID 1 (init process)—each PID namespace has its own PID 1

'''How it works:'''

The kernel maintains a separate process tree for each PID namespace. When you create a PID namespace and start a process in it:

* Inside the namespace, that process is PID 1 (like an init system)
* Outside the namespace, that same process has a different PID (e.g., 12345)
* Processes inside cannot see processes outside their namespace tree

'''Example:'''

<syntaxhighlight lang="bash"># On the host
ps aux | wc -l
# Output: 237 processes

# Inside a container
docker exec container ps aux | wc -l
# Output: 5 processes</syntaxhighlight>
The container's processes think they're the only processes on the system. They cannot see the host's other 232 processes.

'''3. Mount Namespace (<code>mnt</code>)'''

The mount namespace isolates the filesystem mount table. This relates directly to Lab 2 where you learned about filesystems and mounting.

'''What it isolates:'''

* Mount points—what is mounted at <code>/</code>, <code>/tmp</code>, <code>/var</code>, etc.
* Root filesystem—each namespace can have a completely different root directory
* Mount propagation—mounts in one namespace don't affect others (by default)

'''How it works:'''

When you create a mount namespace, the new namespace inherits a copy of the parent's mount table. But subsequent mounts/unmounts in the child don't affect the parent.

Containers use this to provide a completely different filesystem:

<syntaxhighlight lang="bash"># On host (Ubuntu)
ls /
bin boot dev etc home lib ...

# In container (Fedora)
docker exec fedora ls /
bin boot dev etc home lib ... # Different files!</syntaxhighlight>
Both see <code>/etc</code>, but they're seeing different directories. The container's <code>/etc/os-release</code> shows Fedora, while the host's shows Ubuntu.

'''Technical implementation:'''

Docker uses OverlayFS (covered later) to construct the container's root filesystem from image layers, then uses pivot_root or chroot to make that directory appear as <code>/</code> to the container's processes.

'''4. UTS Namespace (<code>uts</code>)'''

UTS stands for "Unix Timesharing System"—a historical name. The UTS namespace isolates hostname and domain name.

'''What it isolates:'''

* System hostname (<code>hostname</code> command output)
* Domain name (NIS domain name)

'''How it works:'''

Each UTS namespace can set its own hostname independently of other namespaces.

<syntaxhighlight lang="bash"># On host
hostname
# Output: myserver.example.com

# In container
docker exec container hostname
# Output: a1b2c3d4e5f6 (container ID)</syntaxhighlight>
Containers typically use the container ID as hostname by default, but you can override with <code>--hostname</code>:

<syntaxhighlight lang="bash">docker run --hostname=webserver nginx</syntaxhighlight>
'''5. IPC Namespace (<code>ipc</code>)'''

The IPC namespace isolates System V Inter-Process Communication resources. This relates to Lab 6 where you learned about IPC mechanisms.

'''What it isolates:'''

* System V message queues
* System V semaphore sets
* System V shared memory segments
* POSIX message queues (in <code>/dev/mqueue</code>)

'''Connection to Lab 6:'''

In Lab 6, you learned that processes can communicate via shared memory, message queues, and semaphores. The IPC namespace ensures that processes in different namespaces cannot access each other's IPC objects, even if they use the same IPC keys.

'''Example:'''

<syntaxhighlight lang="bash"># Container A creates shared memory segment with key 1234
docker exec containerA ipcmk -M 1024 -p 1234

# Container B tries to access it
docker exec containerB ipcs -m -k 1234
# Output: no segment found (different IPC namespace)</syntaxhighlight>
'''6. User Namespace (<code>user</code>)'''

The user namespace isolates user IDs (UIDs) and group IDs (GIDs). This is the most complex namespace and provides significant security benefits.

'''What it isolates:'''

* User IDs—UID 0 inside namespace can map to UID 100000 outside
* Group IDs—similar mapping for GIDs
* Capabilities—process can have capabilities inside namespace but not outside
* Security attributes—AppArmor/SELinux contexts

'''How it works:'''

User namespaces allow UID/GID mapping. A process can be root (UID 0) inside the namespace but unprivileged (e.g., UID 100000) outside.

<pre>Inside Container: UID 0 (root)
↓ mapping
Outside Container: UID 100000 (unprivileged)</pre>
'''Security benefit:'''

Even if an attacker compromises a container and gains root privileges inside the container, they're still unprivileged on the host. If they escape the container, they cannot access files owned by actual root.

'''Docker's approach:'''

By default, many Docker configurations share the host's user namespace (for simplicity and compatibility). Rootless Docker and user-remapped Docker use separate user namespaces for enhanced security.

'''7. Cgroup Namespace (<code>cgroup</code>)'''

The cgroup namespace isolates the view of the cgroup hierarchy. Note this is different from cgroups themselves (which we'll cover separately).

'''What it isolates:'''

* View of <code>/proc/self/cgroup</code>
* View of <code>/sys/fs/cgroup</code> hierarchy
* Ability to see other containers' resource constraints

'''How it works:'''

Without cgroup namespaces, a process can read <code>/proc/self/cgroup</code> and see the full path to its cgroup, revealing information about the container orchestration system.

With cgroup namespaces, the process sees itself at the root of the cgroup tree, hiding the real hierarchy.

'''Note:''' This namespace isolates the ''view'' of cgroups, not the enforcement of resource limits. Resource limits are enforced by cgroups themselves (covered in section 4.5).


==== Namespace Identifiers: Understanding /proc/PID/ns/ ====

Every process has a directory at <code>/proc/PID/ns/</code> containing symbolic links to namespace identifiers. These links reveal which namespaces the process belongs to.

'''Examining namespace identifiers:'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/</syntaxhighlight>
'''Example output:'''

<pre>lrwxrwxrwx 1 root root 0 Dec 12 10:30 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 net -> 'net:[4026531992]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:30 uts -> 'uts:[4026531838]'</pre>
'''Understanding the format:'''

Each symlink follows the pattern: <code>namespace_type:[inode_number]</code>

The '''inode number''' is the critical piece of information. It uniquely identifies that specific namespace instance. Think of it as a "namespace ID."

'''Key principle: Same inode = Shared namespace, Different inode = Isolated namespace'''

'''Example from Lab 7:'''

When you created network namespaces in Lab 7, each had a unique network namespace inode:

<syntaxhighlight lang="bash"># Host process
sudo ls -la /proc/$$/ns/net
net -> 'net:[4026531992]' # Host's network namespace

# Process in red namespace
sudo ip netns exec red ls -la /proc/$$/ns/net
net -> 'net:[4026532145]' # Different inode = isolated!

# Process in blue namespace
sudo ip netns exec blue ls -la /proc/$$/ns/net
net -> 'net:[4026532147]' # Also different = also isolated!</syntaxhighlight>
'''Comparing container to host:'''

<syntaxhighlight lang="bash"># Get container's PID on host
docker inspect container --format '{{.State.Pid}}'
# Example output: 12345

# View container's namespaces
sudo ls -la /proc/12345/ns/net
# Output: net -> 'net:[4026533672]'

# View host's namespace
sudo ls -la /proc/$$/ns/net
# Output: net -> 'net:[4026531992]'

# Different inodes! Container is isolated.</syntaxhighlight>
'''Namespace sharing:'''

Sometimes containers intentionally share namespaces. For example:

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
This container shares the host's network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]' # Same as host!</syntaxhighlight>
'''Using namespace identifiers:'''

These symlinks aren't just informational—you can actually use them to enter namespaces:

<syntaxhighlight lang="bash">sudo nsenter --net=/proc/12345/ns/net ip addr show</syntaxhighlight>
This command enters the network namespace of PID 12345 and runs <code>ip addr show</code> inside that namespace. This is how <code>docker exec</code> works under the hood—it uses <code>nsenter</code> to join the container's namespaces.

'''Summary table:'''

{| class="wikitable"
|-
! Namespace Type
! What It Isolates
! Lab Connection
|-
| <code>net</code>
| Network stack (interfaces, IPs, routes, ports)
| Lab 7: You built this manually!
|-
| <code>pid</code>
| Process IDs and process tree
| Lab 3: Process management
|-
| <code>mnt</code>
| Filesystem mounts and root directory
| Lab 2: Mounting and filesystems
|-
| <code>uts</code>
| Hostname and domain name
| -
|-
| <code>ipc</code>
| Shared memory, message queues, semaphores
| Lab 6: IPC mechanisms
|-
| <code>user</code>
| User and group IDs, capabilities
| Lab 4: Users and permissions
|-
| <code>cgroup</code>
| View of cgroup hierarchy
| -
|}


=== Container Images vs Running Containers ===

This distinction is fundamental to understanding Docker and is often a source of confusion.

'''Container Image:'''

A container image is a '''read-only template''' consisting of:

# '''A root filesystem''': All files and directories that will appear in the container (applications, libraries, configuration files)
# '''Metadata''': Information about how to run the container (default command, environment variables, exposed ports, volumes)
# '''Layers''': The filesystem is composed of multiple read-only layers (explained in section 4.4)

'''Characteristics:'''

* '''Immutable''': Once built, an image never changes
* '''Shareable''': Multiple containers can use the same image
* '''Versionable''': Images can have tags (e.g., <code>nginx:1.21</code>, <code>nginx:latest</code>)
* '''Distributable''': Images can be pushed to/pulled from registries (Docker Hub, private registries)
* '''Stored on disk''': Images consume storage even when not running

'''Running Container:'''

A running container is an '''instance''' of an image—a process (or process tree) running in isolated namespaces with its own writable filesystem layer.

'''Characteristics:'''

* '''Ephemeral''': State is lost when the container is removed (unless using volumes)
* '''Mutable''': Can make changes inside the container (install packages, create files)
* '''Process-based''': A container is fundamentally just a Linux process in isolated namespaces
* '''Short-lived''': Containers are typically created, used, and destroyed frequently
* '''Stateful during runtime''': Maintains state while running, but that state disappears on removal

'''Example to illustrate:'''

<syntaxhighlight lang="bash"># Pull an image (download the template)
docker pull nginx

# The image now exists on disk
docker images
# Output shows: nginx latest a1b2c3d4 100MB

# Start first container from this image
docker run -d --name web1 nginx

# Start second container from the same image
docker run -d --name web2 nginx

# Both containers share the same base image filesystem
# But each has its own writable layer and separate namespaces</syntaxhighlight>
Now you have:

* '''One image''' (nginx:latest) on disk
* '''Two containers''' (web1 and web2) running as separate processes
* Each container has its own PID namespace, network namespace, etc.
* Changes in web1 don't affect web2 (isolated writable layers)

'''Verification:'''

<syntaxhighlight lang="bash"># Modify web1
docker exec web1 bash -c "echo 'Hello from web1' > /usr/share/nginx/html/test.txt"

# Check web1
docker exec web1 cat /usr/share/nginx/html/test.txt
# Output: Hello from web1

# Check web2
docker exec web2 cat /usr/share/nginx/html/test.txt
# Output: cat: /usr/share/nginx/html/test.txt: No such file or directory</syntaxhighlight>
The file exists in web1 but not in web2, even though they're from the same image. Each container has its own writable layer.

'''Image to Container Relationship Diagram:'''

<pre> [nginx Image]
(Read-only)
|
┌─────────┴─────────┐
↓ ↓
[Container 1] [Container 2]
(Writable layer) (Writable layer)
(PID namespace) (PID namespace)
(Net namespace) (Net namespace)
(Isolated) (Isolated)</pre>
'''Filesystem perspective:'''

<pre>Image Layers (read-only, shared):
├─ Layer 3: nginx files
├─ Layer 2: nginx dependencies
└─ Layer 1: Base OS (Debian)

Container 1 (writable, unique):
└─ Writable layer: Changes made in container 1

Container 2 (writable, unique):
└─ Writable layer: Changes made in container 2</pre>
'''Why this design?'''

* '''Efficiency''': 100 containers from the same image share one copy of the base filesystem
* '''Speed''': Starting a container doesn't require copying files—just create a new writable layer
* '''Consistency''': All containers from an image start with identical state
* '''Immutability''': Encourages treating containers as disposable—don't modify running containers, rebuild images instead


=== Container Lifecycle and Ephemeral Nature ===

Understanding the container lifecycle is essential for proper container usage. Containers are designed to be ephemeral—short-lived and replaceable.

'''Container States:'''

<pre>┌─────────┐
│ Created │ (Container exists but not running)
└────┬────┘
│ docker start
↓
┌─────────┐
│ Running │ (Processes executing in isolated namespaces)
└────┬────┘
│ docker stop (SIGTERM, then SIGKILL after timeout)
↓
┌─────────┐
│ Stopped │ (Processes terminated, filesystem layer persists)
└────┬────┘
│ docker start (restart with same writable layer)
↓
┌─────────┐
│ Running │
└────┬────┘
│ docker rm (delete container)
↓
┌─────────┐
│ Removed │ (Container and writable layer deleted forever)
└─────────┘</pre>
'''Key lifecycle commands:'''

<syntaxhighlight lang="bash"># Create and start in one step (most common)
docker run nginx

# Create without starting
docker create --name test nginx

# Start existing stopped container
docker start test

# Stop running container (SIGTERM to main process)
docker stop test

# Force stop (SIGKILL)
docker kill test

# Remove stopped container
docker rm test

# Remove running container (force)
docker rm -f test</syntaxhighlight>
'''The Ephemeral Nature:'''

By default, all changes made inside a container are lost when the container is removed:

<syntaxhighlight lang="bash"># Start container
docker run -d --name demo nginx

# Make changes inside
docker exec demo bash -c "echo 'My data' > /tmp/important.txt"
docker exec demo cat /tmp/important.txt
# Output: My data

# Stop and remove container
docker stop demo
docker rm demo

# Try to access the data
docker run --name demo2 nginx
docker exec demo2 cat /tmp/important.txt
# Output: cat: /tmp/important.txt: No such file or directory
# THE DATA IS GONE!</syntaxhighlight>
'''Why ephemeral?'''

This might seem like a limitation, but it's actually a feature that enables important practices:

# '''Immutable Infrastructure''': Don't patch running systems; deploy new versions
# '''Reproducibility''': Every deployment starts from a known state
# '''Testing''': Test environments are identical to production
# '''Rollback''': Easy to roll back to previous image version
# '''Scaling''': Identical containers can be created/destroyed dynamically

'''When you need persistence:'''

For data that must survive container restarts, use '''volumes''' (covered in section 4.7):

<syntaxhighlight lang="bash"># Create named volume
docker volume create mydata

# Use volume in container
docker run -v mydata:/data nginx

# Data in /data survives container removal</syntaxhighlight>
'''Container lifecycle best practices:'''

* '''Treat containers as cattle, not pets''': Don't name them, don't SSH into them to debug, don't manually configure them
* '''Logs go to stdout/stderr''': Not to files inside the container (so <code>docker logs</code> can capture them)
* '''Configuration via environment variables''': Not by editing files inside the container
* '''Data goes in volumes''': Not in the container's writable layer
* '''Short-lived processes''': Containers should start quickly and shut down gracefully

'''Connection to Lab 3:'''

In Lab 3, you learned about process lifecycle (start, run, terminate). Containers follow a similar lifecycle, but operate at a higher level of abstraction—each container lifecycle event actually involves creating/destroying multiple processes in isolated namespaces.


=== Control Groups (cgroups): Resource Limiting ===

Control groups (cgroups) are a Linux kernel feature that limits, accounts for, and isolates resource usage (CPU, memory, disk I/O, network) of process groups. Without cgroups, a runaway container could consume all CPU or memory, starving other containers and crashing the host.

'''The Problem:'''

Without resource limits:

<syntaxhighlight lang="bash"># Malicious or buggy container
docker run -d evil-container

# This container's process could:
# - Consume 100% CPU (slow down everything else)
# - Allocate all available RAM (trigger OOM killer on host)
# - Fill up disk space (crash other containers)
# - Monopolize network bandwidth</syntaxhighlight>
This is unacceptable in multi-tenant environments. You need resource isolation.

'''The Solution: cgroups'''

Cgroups organize processes into hierarchical groups with configurable resource limits. The kernel enforces these limits, preventing processes from exceeding their allocation.

'''Cgroup Controllers:'''

The Linux kernel provides several cgroup controllers, each managing a different resource type:

# '''cpu''': Limits CPU time
#* CPU shares (relative priority)
#* CPU quotas (hard limits)
#* CPU affinity (pin to specific cores)
# '''memory''': Limits RAM usage
#* Hard limits (container killed if exceeded)
#* Soft limits (reclaim memory under pressure)
#* Swap limits
# '''blkio''': Limits disk I/O
#* Read/write bandwidth limits
#* I/O operation rate limits
# '''net_cls/net_prio''': Network bandwidth control
#* Traffic classification
#* Priority settings
# '''pids''': Limits number of processes
#* Prevents fork bombs
# '''cpuset''': Assigns specific CPUs and memory nodes
#* NUMA awareness

'''Docker's cgroup integration:'''

When you start a container with resource limits, Docker configures the appropriate cgroups:

<syntaxhighlight lang="bash">docker run --memory=512m --cpus=1.5 nginx</syntaxhighlight>
Docker creates a cgroup hierarchy at <code>/sys/fs/cgroup/</code> and configures:

* <code>memory.limit_in_bytes = 536870912</code> (512MB)
* <code>cpu.cfs_quota_us</code> and <code>cpu.cfs_period_us</code> to enforce 1.5 CPUs

'''Viewing cgroup settings:'''

<syntaxhighlight lang="bash"># Get container's PID
docker inspect container --format '{{.State.Pid}}'
# Example: 12345

# View memory limit
cat /sys/fs/cgroup/memory/docker/12345/memory.limit_in_bytes
# Output: 536870912

# View CPU quota
cat /sys/fs/cgroup/cpu/docker/12345/cpu.cfs_quota_us
# Output: 150000 (1.5 CPUs)</syntaxhighlight>
'''Common resource limit flags:'''

<syntaxhighlight lang="bash"># Memory limits
--memory=512m # Hard limit: 512MB RAM
--memory-reservation=256m # Soft limit: try to stay under 256MB
--memory-swap=512m # Total memory+swap limit

# CPU limits
--cpus=1.5 # Use at most 1.5 CPU cores
--cpu-shares=512 # Relative CPU priority (default 1024)
--cpuset-cpus=0,1 # Pin to CPU cores 0 and 1

# I/O limits
--device-read-bps=/dev/sda:10mb # Limit read bandwidth
--device-write-bps=/dev/sda:10mb # Limit write bandwidth

# Process limits
--pids-limit=100 # Max 100 processes in container</syntaxhighlight>
'''Testing memory limits:'''

<syntaxhighlight lang="bash"># Run container with 256MB memory limit
docker run -it --memory=256m ubuntu bash

# Inside container, try to allocate 512MB
# (requires 'stress' tool)
apt-get update && apt-get install -y stress
stress --vm 1 --vm-bytes 512M

# Container is killed when exceeding limit
# Output: stress: FAIL: [1] (415) <-- worker 7 got signal 9
# Signal 9 = SIGKILL (OOM killer)</syntaxhighlight>
'''Why cgroups are essential:'''

# '''Multi-tenancy''': Run untrusted workloads safely
# '''Quality of Service''': Guarantee resources for critical applications
# '''Fair sharing''': Prevent one container from monopolizing resources
# '''Predictability''': Know exactly how much resources each container can use
# '''Cost control''': In cloud environments, map cgroups to billing

'''cgroup vs namespace distinction:'''

* '''Namespaces''': Provide ''isolation''
* '''cgroups''': Provide ''resource limits''

Both are necessary for containers. Namespaces prevent containers from seeing each other; cgroups prevent containers from starving each other.


=== Docker Networking: Bridges, veth Pairs, and NAT ===

Docker networking should feel familiar—it uses the exact same mechanisms you built manually in Lab 7. The primary difference is automation: Docker sets up bridges, veth pairs, routes, and NAT rules automatically.

'''Default Docker Network Architecture:'''

When you install Docker, it creates a default bridge network:

<pre>┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Container A │ │ Container B │ │ Container C │
│ 172.17.0.2 │ │ 172.17.0.3 │ │ 172.17.0.4 │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│eth0 │eth0 │eth0
│ │ │
(veth pair) (veth pair) (veth pair)
│ │ │
┌────┴───────────────────┴───────────────────┴────┐
│ docker0 Bridge │
│ 172.17.0.1/16 │
└────────────────────┬─────────────────────────────┘
│
[Host eth0]
│
[Internet]
(via NAT/MASQUERADE)</pre>
'''Component breakdown (all from Lab 7!):'''

'''1. Bridge Interface (<code>docker0</code>)'''

Docker automatically creates a bridge interface when installed:

<syntaxhighlight lang="bash">ip addr show docker0</syntaxhighlight>
'''Expected output:'''

<pre>3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 02:42:8f:a3:f1:2a brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0</pre>
This is '''exactly like <code>br-lab</code>''' from Lab 7:

* Bridge interface acting as virtual switch
* Assigned IP address 172.17.0.1
* Subnet 172.17.0.0/16 (65,536 addresses available)

'''2. veth Pairs'''

For each container, Docker creates a veth pair:

<syntaxhighlight lang="bash">ip link show | grep veth</syntaxhighlight>
'''Expected output:'''

<pre>8: veth7a3f2b1@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0
10: veth9d4e8c2@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0</pre>
'''Decoding this:'''

* <code>veth7a3f2b1@if7</code>: One end of veth pair, connected to bridge (<code>master docker0</code>)
* <code>@if7</code>: Paired with interface index 7 (inside container)

This is '''exactly what you did in Lab 7:'''

<syntaxhighlight lang="bash">sudo ip link add v-host type veth peer name v-client</syntaxhighlight>
Docker does the same thing, automatically.

'''3. Container Network Namespace'''

Each container has its own network namespace (you built these manually in Lab 7!):

<syntaxhighlight lang="bash"># View container's network interfaces
docker exec container ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo

7: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0</pre>
The container sees:

* <code>lo</code>: Its own loopback interface
* <code>eth0@if8</code>: Its end of the veth pair (paired with host's interface index 8)
* IP address from docker0 subnet

'''4. IP Address Assignment'''

Docker acts as a simple DHCP-like service, assigning IPs sequentially:

* First container: 172.17.0.2
* Second container: 172.17.0.3
* Third container: 172.17.0.4
* etc.

'''5. Routing in Container'''

Check the container's routing table:

<syntaxhighlight lang="bash">docker exec container ip route show</syntaxhighlight>
'''Expected output:'''

<pre>default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2</pre>
'''Translation:'''

* Default route: Send all traffic to 172.17.0.1 (the bridge) for routing to internet
* Local route: 172.17.0.0/16 is directly reachable via eth0

This is '''exactly the routing you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo ip netns exec red ip route add default via 10.0.0.1</syntaxhighlight>
'''6. NAT for Internet Access'''

Docker automatically configures iptables/nftables NAT rules (MASQUERADE) so containers can reach the internet:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep MASQUERADE</syntaxhighlight>
'''Expected output:'''

<pre>MASQUERADE all -- 172.17.0.0/16 0.0.0.0/0</pre>
This is '''exactly the NAT you configured in Lab 7''':

<syntaxhighlight lang="bash">sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE</syntaxhighlight>
'''7. Port Mapping (<code>-p</code> flag)'''

When you use <code>-p 8080:80</code>, Docker sets up Destination NAT (DNAT):

<syntaxhighlight lang="bash">docker run -d -p 8080:80 nginx</syntaxhighlight>
Docker adds an iptables DNAT rule:

<syntaxhighlight lang="bash">sudo iptables -t nat -L -n | grep DNAT</syntaxhighlight>
'''Expected output:'''

<pre>DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80</pre>
'''Translation:''' Traffic arriving at host port 8080 is redirected to 172.17.0.2:80

This is also NAT, specifically DNAT (Destination NAT). You encountered source NAT (SNAT/MASQUERADE) in Lab 7.

'''Container-to-Container Communication'''

Containers on the same bridge can communicate directly:

<syntaxhighlight lang="bash"># Container A pings Container B
docker exec containerA ping 172.17.0.3</syntaxhighlight>
The packet flow:

# Container A sends to 172.17.0.2 (Container B's IP)
# Packet goes out Container A's eth0 (through veth pair)
# Arrives on docker0 bridge
# Bridge forwards to veth pair for Container B
# Packet arrives at Container B's eth0

'''No routing through host networking needed'''—the bridge forwards directly (Layer 2 switching).

'''Custom Networks'''

You can create custom bridge networks:

<syntaxhighlight lang="bash">docker network create --subnet=10.20.0.0/24 mynet</syntaxhighlight>
Docker creates a new bridge interface (e.g., <code>br-abc123def456</code>) with subnet 10.20.0.0/24.

Containers on different networks are isolated:

<syntaxhighlight lang="bash">docker run -d --network=mynet --name=isolated nginx</syntaxhighlight>
This container is on <code>mynet</code>, not <code>docker0</code>, so it cannot communicate with containers on the default bridge (different Layer 2 segment).

'''DNS Resolution Between Containers'''

Docker provides automatic DNS resolution for container names within custom networks:

<syntaxhighlight lang="bash">docker network create mynet
docker run -d --network=mynet --name=web nginx
docker run -d --network=mynet --name=app alpine

# From app container
docker exec app ping web
# Resolves 'web' to web container's IP address!</syntaxhighlight>
Docker runs an embedded DNS server (listening on 127.0.0.11 inside containers) that resolves container names to IPs.

'''Network Modes:'''

Docker supports several network modes:

* '''bridge''' (default): Container on docker0 bridge (or custom bridge)
* '''host''': Container shares host's network namespace (no isolation)
* '''none''': No networking (container has only loopback)
* '''container:name''': Share another container's network namespace

'''Example: host mode'''

<syntaxhighlight lang="bash">docker run --network=host nginx</syntaxhighlight>
The container's network namespace inode is the same as the host's:

<syntaxhighlight lang="bash">sudo ls -la /proc/CONTAINER_PID/ns/net
# Output: net -> 'net:[4026531992]' # Same as host!</syntaxhighlight>
Container sees all host's network interfaces and can bind to any port on any interface.

'''Summary:'''

Docker networking uses:

* Bridges (like <code>br-lab</code> from Lab 7)
* veth pairs (like <code>v-host</code> ↔ <code>v-client</code> from Lab 7)
* Network namespaces (like <code>red</code> and <code>blue</code> from Lab 7)
* Routing tables and default routes
* NAT/MASQUERADE for internet access
* DNAT for port mapping


=== Volumes: Persistent and Shared Storage ===

By default, container filesystems are ephemeral—all changes are lost when the container is removed. For data that must persist (databases, user uploads, logs), Docker provides volumes.

'''The Problem:'''

<syntaxhighlight lang="bash"># Start database container
docker run -d --name db postgres

# Database writes data
docker exec db psql -c "CREATE DATABASE myapp;"

# Stop and remove container
docker rm -f db

# Data is GONE FOREVER!</syntaxhighlight>
This is unacceptable for stateful applications.

'''The Solution: Volumes'''

Volumes are directories on the host that are mounted into containers. Data written to volumes persists beyond container lifecycle.

'''Two Volume Types:'''

'''1. Named Volumes (Docker-managed):'''

Docker manages the volume storage location.

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# Use in container
docker run -v mydata:/data nginx

# Data written to /data inside container is stored in:
# /var/lib/docker/volumes/mydata/_data (on host)</syntaxhighlight>
'''Advantages:'''

* Docker manages storage location
* Portable across hosts (can be backed up, restored)
* Works with volume plugins (NFS, cloud storage)

'''Best practice:''' Use named volumes for production databases, critical data.

'''2. Bind Mounts (Host directory):'''

Mount a host directory directly into the container.

<syntaxhighlight lang="bash"># Mount host directory into container
docker run -v /home/user/html:/usr/share/nginx/html nginx</syntaxhighlight>
Any changes in <code>/home/user/html</code> on the host are immediately visible in <code>/usr/share/nginx/html</code> inside the container, and vice versa.

'''Advantages:'''

* Direct access to files from host
* Useful for development (edit code on host, see changes in container immediately)
* No Docker management needed

'''Disadvantages:'''

* Tied to specific host filesystem paths
* Less portable
* Permissions can be tricky (host UID vs. container UID)

<syntaxhighlight lang="bash"># Docker essentially does:
mount --bind /var/lib/docker/volumes/mydata/_data /data</syntaxhighlight>
'''Volume Sharing Between Containers:'''

Multiple containers can share the same volume:

<syntaxhighlight lang="bash"># Create volume
docker volume create shared

# Container 1 writes
docker run -v shared:/data --name writer alpine sh -c "echo 'Hello' > /data/file.txt"

# Container 2 reads
docker run -v shared:/data --name reader alpine cat /data/file.txt
# Output: Hello</syntaxhighlight>
'''Use cases:'''

* Shared configuration between containers
* Log aggregation (multiple containers write logs to shared volume)
* Data processing pipelines (one container produces, another consumes)

'''Volume Lifecycle:'''

<syntaxhighlight lang="bash"># Create volume
docker volume create mydata

# List volumes
docker volume ls

# Inspect volume
docker volume inspect mydata

# Remove volume (only if no containers using it)
docker volume rm mydata

# Remove all unused volumes
docker volume prune</syntaxhighlight>
'''Inspecting Volume Mounts:'''

<syntaxhighlight lang="bash">docker inspect container --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Example output:'''

<syntaxhighlight lang="json">[
{
"Type": "volume",
"Source": "/var/lib/docker/volumes/mydata/_data",
"Destination": "/data",
"Mode": "z",
"RW": true
}
]</syntaxhighlight>
'''Fields:'''

* <code>Type</code>: "volume" or "bind"
* <code>Source</code>: Host-side path
* <code>Destination</code>: Container-side path
* <code>RW</code>: Read-write (true) or read-only (false)

'''Read-Only Volumes:'''

For security, you can mount volumes read-only:

<syntaxhighlight lang="bash">docker run -v mydata:/data:ro nginx</syntaxhighlight>
Container can read <code>/data</code> but cannot write to it.

'''tmpfs Mounts (In-Memory Temporary Storage):'''

For sensitive data that should never touch disk:

<syntaxhighlight lang="bash">docker run --tmpfs /tmp:size=100m nginx</syntaxhighlight>
The <code>/tmp</code> directory is stored in RAM and disappears when the container stops.

'''Best Practices:'''

* '''Named volumes for databases''': Postgres, MySQL, MongoDB
* '''Bind mounts for development''': Code that you're actively editing
* '''tmpfs for secrets''': Temporary credentials, keys
* '''Volume plugins for cloud''': AWS EBS, Azure Disk, GCP Persistent Disk


== Laboratory Exercises ==

The following exercises build progressively, demonstrating how Docker automates the kernel-level primitives you mastered in previous labs. You will install Docker, inspect namespace isolation, explore interactive containers, configure persistent storage, and build a multi-container application with networking and resource limits.


=== Exercise A: Installing Docker ===

'''Objective:''' Install Docker Engine from the official Docker repository and configure it for non-root access.

'''Why the official repository?''' Ubuntu's default repositories often contain outdated Docker versions. The official Docker repository provides the latest stable releases with security updates and new features.

'''Step 1: Remove old Docker versions (if any)'''

If you previously installed Docker from Ubuntu's repositories or older Docker installations exist, remove them to avoid conflicts:

<syntaxhighlight lang="bash">sudo apt remove docker docker-engine docker.io containerd runc</syntaxhighlight>
It's safe to run this even if these packages aren't installed—apt will simply report they're not present.

'''Step 2: Install prerequisites'''

Install packages needed for adding Docker's repository:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
apt-transport-https \
ca-certificates \
curl \
gnupg \
lsb-release</syntaxhighlight>
'''Step 3: Add Docker's GPG key'''

Docker signs its packages with a GPG key to ensure authenticity. Add this key to your system:

<syntaxhighlight lang="bash">sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg</syntaxhighlight>
'''What this does:'''

* Creates <code>/etc/apt/keyrings/</code> directory for storing repository keys
* Downloads Docker's GPG public key
* Converts it to binary format (<code>.gpg</code> file)
* Makes it readable by all users

'''Step 4: Add Docker repository to apt sources'''

<syntaxhighlight lang="bash">sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF</syntaxhighlight>
'''What this does:'''

* Detects your CPU architecture (amd64, arm64, etc.)
* Detects your Ubuntu version codename (focal, jammy, etc.)
* Adds Docker's repository to apt's source list

'''Step 5: Install Docker Engine'''

Update package index and install Docker:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y \
docker-ce \
docker-ce-cli \
containerd.io \
docker-buildx-plugin \
docker-compose-plugin</syntaxhighlight>
'''Packages installed:'''

* <code>docker-ce</code>: Docker Community Edition engine (the main Docker daemon)
* <code>docker-ce-cli</code>: Docker command-line interface
* <code>containerd.io</code>: Container runtime that Docker uses under the hood
* <code>docker-buildx-plugin</code>: Extended build capabilities (multi-platform images)
* <code>docker-compose-plugin</code>: Docker Compose for multi-container applications

'''Step 6: Verify Docker installation'''

Check Docker version:

<syntaxhighlight lang="bash">sudo docker --version</syntaxhighlight>
'''Expected output:'''

<pre>Docker version 24.0.7, build afdd53b</pre>
Your version number may be different (newer), which is fine.

'''Step 7: Start and enable Docker service'''

Ensure Docker daemon starts on boot:

<syntaxhighlight lang="bash">sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
Check service status:

<syntaxhighlight lang="bash">sudo systemctl status docker</syntaxhighlight>
'''Expected output:'''

<pre>● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled)
Active: active (running) since Thu 2024-12-12 10:30:00 UTC; 5min ago</pre>
Look for <code>Active: active (running)</code>.

'''Step 8: Configure non-root Docker access'''

By default, only root can run Docker commands. To run Docker without <code>sudo</code>, add your user to the <code>docker</code> group:

<syntaxhighlight lang="bash">sudo usermod -aG docker $USER</syntaxhighlight>
'''Important:''' Log out and log back in for this change to take effect. Alternatively, you can run:

<syntaxhighlight lang="bash">newgrp docker</syntaxhighlight>
This starts a new shell with updated group membership.

'''Step 9: Verify non-root access'''

Test that you can run Docker without sudo:

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
If this works without errors, you've successfully installed Docker!

'''Expected output:'''

<pre>Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
c1ec31eb5944: Pull complete
Digest: sha256:4bd78111b6914a99dbc560e6a20eab57ff6655aea4a80c50b0c5491968cbc2e6
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/</pre>
'''What happened:'''

# Docker client (<code>docker</code> command) connected to Docker daemon (dockerd)
# Daemon checked local images—didn't find <code>hello-world</code>
# Daemon pulled <code>hello-world</code> image from Docker Hub (public registry)
# Daemon created container from image
# Container executed its program (printed the message)
# Container exited
# Output sent back to your terminal

'''Step 10: Clean up test container'''

List all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
You should see the hello-world container with status <code>Exited (0)</code>.

Remove it:

<syntaxhighlight lang="bash">docker rm $(docker ps -aq --filter "ancestor=hello-world")</syntaxhighlight>
Verify it's gone:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Deliverable A:'''

Provide screenshots showing:

# Output of <code>docker --version</code>
# Output of <code>sudo systemctl status docker</code> (showing Active: active (running))
# Output of <code>docker run hello-world</code> (the entire message)


=== Exercise B: Hello World and Namespace Inspection ===

'''Objective:''' Run your first container, understand the container lifecycle, and inspect the Linux kernel namespaces that provide container isolation—connecting directly to your work in Lab 7.


==== Part 1: Hello World ====

'''Step 1: Run the hello-world container (if not done in Exercise A)'''

<syntaxhighlight lang="bash">docker run hello-world</syntaxhighlight>
We covered this in Exercise A, but let's examine what actually happened in more detail.

'''Step 2: List all containers'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:''' Nothing (empty list)

'''Why?''' The hello-world container ran, printed its message, and exited immediately. <code>docker ps</code> only shows running containers by default.

To see all containers (including stopped):

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 hello-world "/hello" 10 seconds ago Exited (0) 8 seconds ago eager_tesla</pre>
'''Understanding the fields:'''

* '''CONTAINER ID''': Short hex identifier (first 12 chars of full 64-char ID)
* '''IMAGE''': Which image this container was created from
* '''COMMAND''': The process that ran inside the container (<code>/hello</code> executable)
* '''CREATED''': When the container was created
* '''STATUS''': Current state—<code>Exited (0)</code> means process exited with code 0 (success)
* '''PORTS''': Port mappings (none for hello-world)
* '''NAMES''': Random name if you don't specify one (Docker generates names like "eager_tesla", "hopeful_darwin")

'''Step 3: Inspect the container'''

Get detailed information about the container:

<syntaxhighlight lang="bash">docker inspect eager_tesla # Use your actual container name</syntaxhighlight>
This outputs a large JSON document with all container metadata. Let's extract specific fields:

<syntaxhighlight lang="bash"># Just the State section
docker inspect eager_tesla --format='{{json .State}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output (formatted):'''

<syntaxhighlight lang="json">{
"Status": "exited",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 0,
"StartedAt": "2024-12-12T10:35:00Z",
"FinishedAt": "2024-12-12T10:35:01Z"
}</syntaxhighlight>
'''Analysis:'''

* Container ran for about 1 second (started at :00, finished at :01)
* Exit code 0 (successful completion)
* PID is 0 (process has terminated; while running it had a real PID)

'''Step 4: View container logs'''

Even though the container exited, Docker saved its output:

<syntaxhighlight lang="bash">docker logs eager_tesla</syntaxhighlight>
Shows the hello-world message again. This demonstrates that Docker captures stdout/stderr from containers.

'''Step 5: Remove the container'''

Stopped containers still consume disk space (their writable layer persists). Remove it:

<syntaxhighlight lang="bash">docker rm eager_tesla</syntaxhighlight>
Verify removal:

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
The container should be gone.


==== Part 2: Inspect Namespaces (Connect to Lab 7!) ====

Now let's run a longer-lived container and examine its namespace isolation—this directly connects to your hands-on work with network namespaces in Lab 7.

'''Step 1: Run a persistent container'''

<syntaxhighlight lang="bash">docker run -d --name inspector nginx</syntaxhighlight>
'''Flags explained:'''

* <code>-d</code>: Detached mode—run in background
* <code>--name inspector</code>: Give it a memorable name instead of random name

'''Expected output:'''

<pre>Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
Status: Downloaded newer image for nginx:latest
b7f9a8e6c4d3a1b2c5e8f9d2a7c4b6e8f3d9a2c1b4e7f8d3a5c2b1</pre>
The long hex string is the full 64-character container ID. Docker returns this after creating the container.

'''Step 2: Verify the container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b7f9a8e6c4d3 nginx "/docker-entrypoint.…" 10 seconds ago Up 8 seconds 80/tcp inspector</pre>
The container is running nginx web server.

'''Step 3: Get the container's PID on the host'''

Remember: containers are just processes. Let's find the PID:

<syntaxhighlight lang="bash">docker inspect inspector --format '{{.State.Pid}}'</syntaxhighlight>
'''Expected output:''' A number like <code>12345</code>

This is the process ID on the '''host''' system. Let's verify:

<syntaxhighlight lang="bash">ps aux | grep 12345</syntaxhighlight>
You should see nginx processes! The container is just a process with a fancy namespace wrapper.

'''Step 4: Examine the container's namespaces'''

This is the crucial step connecting to Lab 7. Replace 12345 with your actual PID:

<syntaxhighlight lang="bash">sudo ls -la /proc/12345/ns/</syntaxhighlight>
'''Expected output:'''

<pre>total 0
dr-x--x--x 2 root root 0 Dec 12 10:40 .
dr-xr-xr-x 9 root root 0 Dec 12 10:40 ..
lrwxrwxrwx 1 root root 0 Dec 12 10:40 cgroup -> 'cgroup:[4026533671]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 ipc -> 'ipc:[4026533669]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 mnt -> 'mnt:[4026533667]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 net -> 'net:[4026533672]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid -> 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 pid_for_children -> 'pid:[4026533670]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 12 10:40 uts -> 'uts:[4026533668]'</pre>
'''Analysis of namespace inodes:'''

Note the inode numbers (the numbers in brackets). Each represents a namespace instance.

'''Step 5: Compare with host's namespaces'''

<syntaxhighlight lang="bash">sudo ls -la /proc/$$/ns/net</syntaxhighlight>
'''Expected output:'''

<pre>lrwxrwxrwx 1 youruser youruser 0 Dec 12 10:40 net -> 'net:[4026531992]'</pre>
'''Critical observation:''' The container's network namespace inode (<code>4026533672</code>) is '''different''' from the host's (<code>4026531992</code>).

'''Step 6: Compare two containers'''

Start a second container:

<syntaxhighlight lang="bash">docker run -d --name inspector2 nginx</syntaxhighlight>
Get its PID:

<syntaxhighlight lang="bash">docker inspect inspector2 --format '{{.State.Pid}}'</syntaxhighlight>
Check its network namespace:

<syntaxhighlight lang="bash">sudo ls -la /proc/NEW_PID/ns/net</syntaxhighlight>
'''Expected:''' A different inode number from both the host and <code>inspector</code> container!

'''Conclusion:''' Each container has its own isolated network namespace, just like the red and blue namespaces you created manually in Lab 7.

'''Step 7: Examine other namespaces'''

Let's check PID namespace isolation:

<syntaxhighlight lang="bash"># Host PID namespace
sudo ls -la /proc/$$/ns/pid

# Container PID namespace
sudo ls -la /proc/CONTAINER_PID/ns/pid</syntaxhighlight>
Different inodes = isolated process trees!

'''Step 8: User namespace (often shared)'''

<syntaxhighlight lang="bash"># Host user namespace
sudo ls -la /proc/$$/ns/user

# Container user namespace
sudo ls -la /proc/CONTAINER_PID/ns/user</syntaxhighlight>
'''Expected:''' Often the '''same''' inode number.

Many Docker configurations share the host's user namespace for simplicity. This means UID 0 in the container is UID 0 on the host (less secure, but more compatible).

For enhanced security, Docker can be configured to use separate user namespaces (rootless Docker), but that's beyond this lab's scope.

'''Step 9: Enter the container's namespace with nsenter'''

You can actually enter a container's namespaces using the <code>nsenter</code> command (this is how <code>docker exec</code> works!):

<syntaxhighlight lang="bash">sudo nsenter --target CONTAINER_PID --net ip addr show</syntaxhighlight>
This executes <code>ip addr show</code> inside the container's network namespace, showing the container's view of network interfaces.

'''Step 10: Clean up'''

<syntaxhighlight lang="bash">docker stop inspector inspector2
docker rm inspector inspector2</syntaxhighlight>

=== Deliverable B ===

Provide screenshots showing:

# Output of <code>docker run hello-world</code> (the full hello message)
# Output of <code>docker ps -a</code> showing the exited hello-world container with its random name
# Output of <code>docker inspect inspector --format '{{.State.Pid}}'</code> (showing the PID)
# Output of <code>sudo ls -la /proc/PID/ns/</code> for the inspector container (showing all namespaces)
# Side-by-side comparison:
#* <code>sudo ls -la /proc/$$/ns/net</code> (host's network namespace inode)
#* <code>sudo ls -la /proc/CONTAINER_PID/ns/net</code> (container's network namespace inode)
#* Highlight that the inode numbers are different


=== Exercise C: Interactive Exploration with Fedora ===

'''Objective:''' Run an interactive container with a different Linux distribution (Fedora instead of Ubuntu), demonstrating mount namespace isolation (different root filesystems), PID namespace isolation (isolated process tree), and UTS namespace isolation (different hostname).

'''Important context:''' Your host might be running Ubuntu, but the container will run Fedora. Both will be using the same Linux kernel, but they'll have completely different filesystems and will appear as different "machines" from inside.

'''Step 1: Run Fedora container interactively'''

<syntaxhighlight lang="bash">docker run -it --name fedora-explore fedora bash</syntaxhighlight>
'''Flags explained:'''

* <code>-i</code>: Interactive—keep STDIN open
* <code>-t</code>: Allocate pseudo-TTY (terminal)
* <code>fedora</code>: Pull Fedora base image from Docker Hub
* <code>bash</code>: Command to run inside container (start bash shell)

'''What happens:'''

# Docker downloads Fedora base image (if not cached)
# Creates container from image
# Starts bash inside the container
# Attaches your terminal to that bash session

'''Expected output:'''

<pre>Unable to find image 'fedora:latest' locally
latest: Pulling from library/fedora
...
Status: Downloaded newer image for fedora:latest
[root@a1b2c3d4e5f6 /]#</pre>
'''Observe the prompt change:'''

* Before: <code>user@hostname:~$</code> (your normal shell)
* After: <code>[root@a1b2c3d4e5f6 /]#</code> (inside container)

You're now '''inside''' the Fedora container!

'''Step 2: Explore the filesystem (Mount Namespace)'''

Check the operating system:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output:'''

<pre>NAME="Fedora Linux"
VERSION="39 (Container Image)"
ID=fedora
VERSION_ID=39
...</pre>
Open a '''new terminal''' on your host (don't close the container terminal) and run:

<syntaxhighlight lang="bash">cat /etc/os-release</syntaxhighlight>
'''Expected output on host:'''

<pre>NAME="Ubuntu"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
ID=ubuntu
...</pre>
'''Two different operating systems on the same machine!''' This is mount namespace isolation—the container has its own root filesystem.

'''Back in the container''', explore the filesystem:

<syntaxhighlight lang="bash">ls /</syntaxhighlight>
'''Expected output:'''

<pre>bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var</pre>
These are Fedora's files, not your host's Ubuntu files. They're completely different directory trees.

'''Try to use Ubuntu's package manager:'''

<syntaxhighlight lang="bash">apt update</syntaxhighlight>
'''Expected output:'''

<pre>bash: apt: command not found</pre>
apt doesn't exist in Fedora! Fedora uses a different package manager.

'''Try Fedora's package manager:'''

<syntaxhighlight lang="bash">dnf --version</syntaxhighlight>
'''Expected output:'''

<pre>4.18.2
Installed: dnf-0:4.18.2-1.fc39.noarch
...</pre>
dnf exists because we're in a Fedora environment.

'''Install a package:'''

<syntaxhighlight lang="bash">dnf install -y nano</syntaxhighlight>
This works! We can install packages just like on a real Fedora system.

'''Connection to Lab 2:'''

In Lab 2, you learned about the filesystem hierarchy (<code>/etc</code>, <code>/var</code>, <code>/usr</code>, etc.). Mount namespaces let the container have completely different contents at these paths. The container's <code>/etc</code> is different from the host's <code>/etc</code>.

'''Step 3: Examine process isolation (PID Namespace)'''

Inside the container, check running processes:

<syntaxhighlight lang="bash">ps aux</syntaxhighlight>
'''Expected output:'''

<pre>USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 12345 2345 pts/0 Ss 10:45 0:00 bash
root 67 0.0 0.0 44567 3456 pts/0 R+ 10:47 0:00 ps aux</pre>
'''Only two processes visible!'''

* PID 1: bash (the container's init process)
* PID 67: ps command we just ran

'''On the host''' (in your other terminal):

<syntaxhighlight lang="bash">ps aux | wc -l</syntaxhighlight>
'''Expected output:''' 200+ processes

'''The container cannot see the host's processes!''' This is PID namespace isolation.

'''From the container's perspective, bash is PID 1''' (like systemd is PID 1 on a normal Linux system).

'''From the host's perspective, that same bash process has a different PID''' (e.g., 12345).

'''Connection to Lab 3:'''

In Lab 3, you learned about PIDs and the process hierarchy. PID namespaces create separate process hierarchies—the container has its own process tree starting from PID 1.

'''Step 4: Check hostname (UTS Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>a1b2c3d4e5f6</pre>
This is the container ID (first 12 characters of the full container ID).

'''On the host:'''

<syntaxhighlight lang="bash">hostname</syntaxhighlight>
'''Expected output:'''

<pre>your-hostname.example.com</pre>
Different hostnames! This is UTS namespace isolation.

'''Step 5: Examine network configuration (Network Namespace)'''

Inside the container:

<syntaxhighlight lang="bash">ip addr show</syntaxhighlight>
'''Expected output:'''

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever

17: eth0@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever</pre>
'''Analysis:'''

* <code>lo</code>: Container's loopback interface (127.0.0.1)
* <code>eth0@if18</code>: Container's network interface (part of veth pair)
** <code>@if18</code>: Indicates this interface is paired with interface index 18 (on the host)
** IP address: 172.17.0.2 (from docker0 bridge subnet)

'''On the host:'''

<syntaxhighlight lang="bash">ip addr show | grep "172.17"</syntaxhighlight>
You should see the docker0 bridge has IP 172.17.0.1, and you might see veth interfaces for containers.

'''Connection to Lab 7:'''

This is '''exactly''' what you built manually!

* docker0 bridge ≈ br-lab from Lab 7
* Container's eth0 ≈ v-client from Lab 7
* veth pair connects container to bridge ≈ Lab 7's veth pair architecture

'''Step 6: Test internet connectivity from container'''

<syntaxhighlight lang="bash">ping -c 3 8.8.8.8</syntaxhighlight>
'''Expected:''' Ping succeeds!

This works because:

# Container has default route to 172.17.0.1 (docker0 bridge)
# Host has IP forwarding enabled
# Host has NAT rule (MASQUERADE) for 172.17.0.0/16

'''This is identical to what you configured in Lab 7!'''

'''Step 7: Try to see host's processes (will fail)'''

<syntaxhighlight lang="bash">ps aux | grep systemd</syntaxhighlight>
'''Expected:''' No systemd processes visible.

You cannot see the host's processes from inside the container (PID namespace isolation).

'''Step 8: Exit the container'''

<syntaxhighlight lang="bash">exit</syntaxhighlight>
When you exit bash (PID 1 in the container), the container stops automatically.

'''Verify the container stopped:'''

<syntaxhighlight lang="bash">docker ps -a</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS NAMES
a1b2c3d4e5f6 fedora "bash" 5 minutes ago Exited (0) 10 seconds ago fedora-explore</pre>
'''Note:''' The container still exists (STATUS: Exited), but it's not running. You can restart it with <code>docker start fedora-explore</code> if needed.

'''Step 9: Clean up'''

<syntaxhighlight lang="bash">docker rm fedora-explore</syntaxhighlight>

=== Deliverable C ===

Provide screenshots showing:

# '''Inside container''': Output of <code>cat /etc/os-release</code> (showing Fedora)
# '''On host''': Output of <code>cat /etc/os-release</code> (showing Ubuntu or your host OS)
# '''Inside container''': Output of <code>ps aux</code> (showing minimal processes, bash as PID 1)
# '''On host''': Output of <code>ps aux | wc -l</code> (showing many more processes)
# '''Inside container''': Output of <code>hostname</code> (showing container ID)
# '''On host''': Output of <code>hostname</code> (showing host's hostname)
# '''Inside container''': Output of <code>ip addr show</code> (showing eth0 with 172.17.0.x address)
# Brief explanation (4-5 sentences): What do these differences demonstrate about namespace isolation? How does this relate to what you learned in Labs 2, 3, and 7?


=== Exercise D: Persistent Storage with Caddy ===

'''Objective:''' Run Caddy web server with persistent configuration and content using bind mounts, demonstrating that data can survive container removal and be shared between host and container.

Caddy is the web server you've been using throughout Lab 9. We'll run it in a container and configure it using files from the host.


==== Part 1: Basic Caddy Container ====

'''Step 1: Create directory structure on host'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-caddy/{site,data,config}</syntaxhighlight>
'''Directory purposes:'''

* <code>site</code>: Website content (HTML files)
* <code>data</code>: Caddy's data directory (certificates, storage)
* <code>config</code>: Caddy configuration (Caddyfile)

'''Step 2: Create a simple website'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/site/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Docker Caddy Demo</title>
</head>
<body>
<h1>Hello from Dockerized Caddy!</h1>
<div>
This is running in a Docker container.
The file you're viewing is mounted from the host filesystem.
Changes made on the host appear instantly in the container!
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 3: Create Caddyfile configuration'''

<syntaxhighlight lang="bash">cat > ~/lab10-caddy/config/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Caddyfile explanation:'''

* <code>:80</code>: Listen on port 80 (inside container)
* <code>root * /usr/share/caddy</code>: Serve files from this directory
* <code>file_server</code>: Enable static file serving
* <code>log</code>: Send access logs to stdout (so <code>docker logs</code> can capture them)

'''Step 4: Run Caddy container with volume mounts'''

<syntaxhighlight lang="bash">docker run -d \
--name caddy-persistent \
-p 8080:80 \
-v ~/lab10-caddy/site:/usr/share/caddy \
-v ~/lab10-caddy/data:/data \
-v ~/lab10-caddy/config:/etc/caddy \
caddy</syntaxhighlight>
'''Breaking down the command:'''

* <code>-d</code>: Detached mode (run in background)
* <code>--name caddy-persistent</code>: Give container a memorable name
* <code>-p 8080:80</code>: Port mapping
** Host port 8080 → Container port 80
** This is NAT (DNAT specifically) from Lab 7!
* <code>-v ~/lab10-caddy/site:/usr/share/caddy</code>: Bind mount
** Host directory <code>~/lab10-caddy/site</code> appears at <code>/usr/share/caddy</code> inside container
** Bidirectional: changes on either side are visible on both sides
* <code>-v ~/lab10-caddy/data:/data</code>: Caddy's data storage
* <code>-v ~/lab10-caddy/config:/etc/caddy</code>: Caddy's configuration
* <code>caddy</code>: Image to use

'''Expected output:'''

<pre>Unable to find image 'caddy:latest' locally
latest: Pulling from library/caddy
...
Status: Downloaded newer image for caddy:latest
f8e9c7b6d5a4e3b2c1f7d8a9e6b5c4d3a2f1e8d7c6b5a4e3d2c1b9f8</pre>
'''Step 5: Verify container is running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f8e9c7b6d5a4 caddy "caddy run..." 10 seconds ago Up 8 seconds 0.0.0.0:8080->80/tcp caddy-persistent</pre>
'''Note the PORTS column:''' <code>0.0.0.0:8080->80/tcp</code>

This means:

* Listen on all host interfaces (<code>0.0.0.0</code>)
* Host port 8080 maps to container port 80
* Protocol: TCP

'''Step 6: Test the web server'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected output:''' Your HTML page!

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
<head>
<title>Docker Caddy Demo</title>
...
<h1>Hello from Dockerized Caddy!</h1>
...
</html></syntaxhighlight>
You can also open <code>http://localhost:8080</code> in a web browser on your host.

'''Step 7: View Caddy logs'''

<syntaxhighlight lang="bash">docker logs caddy-persistent</syntaxhighlight>
'''Expected output:'''

<pre>{"level":"info","ts":1702389123.456,"msg":"using provided configuration",...}
{"level":"info","ts":1702389123.789,"msg":"serving initial configuration"}
...</pre>
These are Caddy's startup logs. When you access the website, you'll see access logs here too.


==== Part 2: Inspect Mounts ====

'''Step 8: Inspect the container's mounts'''

<syntaxhighlight lang="bash">docker inspect caddy-persistent --format='{{json .Mounts}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">[
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/site",
"Destination": "/usr/share/caddy",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/data",
"Destination": "/data",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Type": "bind",
"Source": "/home/youruser/lab10-caddy/config",
"Destination": "/etc/caddy",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
}
]</syntaxhighlight>
'''Field explanations:'''

* <code>Type</code>: "bind" (bind mount, not Docker-managed volume)
* <code>Source</code>: Host filesystem path
* <code>Destination</code>: Path inside container
* <code>RW</code>: true (read-write), false would be read-only
* <code>Propagation</code>: How mount events propagate (rprivate = don't propagate to other mounts)

'''Step 9: View from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent df -h | grep caddy</syntaxhighlight>
Shows mounted filesystems inside the container containing "caddy" in the path.

You can also list the files:

<syntaxhighlight lang="bash">docker exec caddy-persistent ls -la /usr/share/caddy</syntaxhighlight>
'''Expected output:'''

<pre>total 12
drwxr-xr-x 2 root root 4096 Dec 12 10:50 .
drwxr-xr-x 1 root root 4096 Dec 12 10:50 ..
-rw-r--r-- 1 root root 687 Dec 12 10:50 index.html</pre>
This is the same <code>index.html</code> you created on the host!


==== Part 3: Test Persistence ====

'''Step 10: Modify the file on the host'''

'''Without stopping the container''', edit the HTML file:

<syntaxhighlight lang="bash">cat >> ~/lab10-caddy/site/index.html << 'EOF'
<div class="info">
🎉 This was added from the host!
The container is still running, and changes appear instantly.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 11: Verify the change appears in the container immediately'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' The new section appears!

You didn't restart the container, yet the content changed. This demonstrates '''bidirectional bind mount synchronization'''.

'''Step 12: Create a new file from inside the container'''

<syntaxhighlight lang="bash">docker exec caddy-persistent bash -c "echo '<h2>Created from container</h2>' > /usr/share/caddy/test.html"</syntaxhighlight>
'''Step 13: Verify the file appears on the host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected output:'''

<pre>total 16
drwxr-xr-x 2 youruser youruser 4096 Dec 12 11:00 .
drwxr-xr-x 5 youruser youruser 4096 Dec 12 10:45 ..
-rw-r--r-- 1 youruser youruser 687 Dec 12 10:50 index.html
-rw-r--r-- 1 root root 34 Dec 12 11:00 test.html ← New file!</pre>
The file exists on the host! Changes flow both directions.

'''Note:''' The file is owned by <code>root</code> because the process inside the container runs as root. This is one of the complexities of bind mounts—UID/GID mapping between host and container.

'''Step 14: Stop and remove the container'''

<syntaxhighlight lang="bash">docker stop caddy-persistent
docker rm caddy-persistent</syntaxhighlight>
'''Step 15: Verify files still exist on host'''

<syntaxhighlight lang="bash">ls -la ~/lab10-caddy/site/</syntaxhighlight>
'''Expected:''' All files still there!

The files survive because they're stored on the host filesystem, not in the container's ephemeral writable layer.

'''Step 16: Start a NEW container with the same bind mounts'''

<syntaxhighlight lang="bash">docker run -d \
--name caddy-new \
-p 8080:80 \
-v ~/lab10-caddy/site:/usr/share/caddy \
-v ~/lab10-caddy/data:/data \
-v ~/lab10-caddy/config:/etc/caddy \
caddy</syntaxhighlight>
'''Step 17: Verify persistence'''

<syntaxhighlight lang="bash">curl http://localhost:8080</syntaxhighlight>
'''Expected:''' All your previous content is still there!

The website works immediately because all the content and configuration was stored on the host, not inside the old container.

'''Step 18: Compare to ephemeral storage'''

Let's demonstrate what happens without volumes:

<syntaxhighlight lang="bash"># Start container without volumes
docker run -d --name caddy-temp caddy

# Create file inside container
docker exec caddy-temp bash -c "echo 'temporary' > /tmp/temp.txt"

# Verify file exists
docker exec caddy-temp cat /tmp/temp.txt
# Output: temporary

# Stop and remove container
docker stop caddy-temp
docker rm caddy-temp

# Try to access the file in a new container
docker run -d --name caddy-temp2 caddy
docker exec caddy-temp2 cat /tmp/temp.txt
# Output: cat: /tmp/temp.txt: No such file or directory

# The file is GONE because it was in the ephemeral layer</syntaxhighlight>
'''Step 19: Clean up'''

<syntaxhighlight lang="bash">docker stop caddy-new
docker rm caddy-new</syntaxhighlight>
The files in <code>~/lab10-caddy/</code> remain intact on your host.

<syntaxhighlight lang="bash"># What Docker essentially does:
mount --bind ~/lab10-caddy/site /var/lib/docker/overlay2/.../merged/usr/share/caddy</syntaxhighlight>

=== Deliverable D ===

Provide screenshots showing:

# Output of <code>curl http://localhost:8080</code> showing your custom HTML (initial version)
# Output of <code>docker inspect caddy-persistent --format='{{json .Mounts}}'</code> (formatted with python3 -m json.tool)
# After modifying <code>index.html</code> on the host, output of <code>curl http://localhost:8080</code> showing the new content (without restarting container)
# Output of <code>ls -la ~/lab10-caddy/site/</code> showing both <code>index.html</code> and the <code>test.html</code> created from inside the container
# After removing the original container and starting <code>caddy-new</code>, output of <code>curl http://localhost:8080</code> demonstrating that content persisted


=== Exercise E: Multi-Container Infrastructure with Networking and Resource Limits ===

'''Objective:''' Build a complete three-tier architecture with:

* '''Purple''' container acting as reverse proxy (routes requests based on URL path)
* '''Red''' container serving backend content (memory-limited)
* '''Blue''' container serving backend content (CPU-limited)

This exercise synthesizes everything from Labs 7-9:

* Custom networks (Lab 7 bridges)
* Container-to-container communication (Lab 7 veth pairs and routing)
* Reverse proxy with path-based routing (Lab 9 Caddy configuration)
* Resource limits (cgroups)


==== Part 1: Create a Custom Network ====

'''Step 1: Create a custom bridge network'''

<syntaxhighlight lang="bash">docker network create --subnet=10.10.0.0/24 labnet</syntaxhighlight>
This creates a new bridge (just like <code>br-lab</code> from Lab 7) with subnet 10.10.0.0/24.

'''Expected output:'''

<pre>a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2</pre>
This is the network ID.

'''Step 2: Inspect the network'''

<syntaxhighlight lang="bash">docker network inspect labnet</syntaxhighlight>
'''Expected output (abbreviated):'''

<syntaxhighlight lang="json">[
{
"Name": "labnet",
"Id": "a1b2c3d4e5f6...",
"Driver": "bridge",
"IPAM": {
"Config": [
{
"Subnet": "10.10.0.0/24",
"Gateway": "10.10.0.1"
}
]
},
"Containers": {},
...
}
]</syntaxhighlight>
'''Key observations:'''

* <code>Driver: "bridge"</code>: Uses bridge networking (Layer 2 switching)
* <code>Subnet: "10.10.0.0/24"</code>: Our specified subnet
* <code>Gateway: "10.10.0.1"</code>: Docker automatically assigns .1 as gateway
* <code>Containers: {}</code>: No containers connected yet

'''Step 3: Verify bridge creation on host'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
'''Expected output:'''

<pre>5: br-a1b2c3d4e5f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default</pre>
Docker created a new bridge interface! The name includes the network ID prefix.

You can also use:

<syntaxhighlight lang="bash">brctl show</syntaxhighlight>
'''Expected output:'''

<pre>bridge name bridge id STP enabled interfaces
br-a1b2c3d4e5f6 8000.0242a1b2c3d4 no
docker0 8000.0242f7a8b9c0 no</pre>
Two bridges:

* <code>docker0</code>: Default Docker bridge
* <code>br-a1b2c3d4e5f6</code>: Our custom labnet bridge

'''Connection to Lab 7:'''

This is '''exactly''' what you did with:

<syntaxhighlight lang="bash">sudo ip link add br-lab type bridge
sudo ip link set br-lab up
sudo ip addr add 10.0.0.1/24 dev br-lab</syntaxhighlight>
'''Docker automated it!'''


==== Part 2: Create Backend Services (Red and Blue) ====

'''Step 4: Create content directories'''

<syntaxhighlight lang="bash">mkdir -p ~/lab10-multicontainer/{red,blue,purple}</syntaxhighlight>
'''Step 5: Create Red service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Red Service</title>
</head>
<body>
<div>
Container: Red
IP: 10.10.0.2
Resource Limit: Memory capped at 256MB
This backend is memory-constrained by cgroups.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 6: Create Red Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/red/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Step 7: Create Blue service content'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/index.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
<title>Blue Service</title>
</head>
<body>
<h1>Blue Service</h1>
<div class="info">
Container: Blue
IP: 10.10.0.3
Resource Limit: CPU capped at 0.5 cores
This backend is CPU-constrained by cgroups.
</div>
</body>
</html>
EOF</syntaxhighlight>
'''Step 8: Create Blue Caddyfile'''

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/blue/Caddyfile << 'EOF'
:80 {
root * /usr/share/caddy
file_server

log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Step 9: Start Red container with memory limit'''

<syntaxhighlight lang="bash">docker run -d \
--name red \
--network labnet \
--ip 10.10.0.2 \
--memory=256m \
--memory-swap=256m \
-v ~/lab10-multicontainer/red:/etc/caddy \
-v ~/lab10-multicontainer/red:/usr/share/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--network labnet</code>: Connect to our custom network (not default docker0)
* <code>--ip 10.10.0.2</code>: Assign static IP address (just like <code>ip addr add</code> in Lab 7!)
* <code>--memory=256m</code>: cgroup memory limit (hard cap: 256MB RAM)
* <code>--memory-swap=256m</code>: Total memory+swap limit (setting equal to memory means no swap)
** If swap was 512m, container could use 256MB RAM + 256MB swap
* <code>-v ~/lab10-multicontainer/red:/etc/caddy</code>: Mount Caddyfile
* <code>-v ~/lab10-multicontainer/red:/usr/share/caddy</code>: Mount website content

'''Expected output:''' Container ID

'''Step 10: Verify Red is running'''

<syntaxhighlight lang="bash">docker ps --filter "name=red"</syntaxhighlight>
'''Step 11: Test Red directly'''

Since Red has IP 10.10.0.2, let's verify we can reach it:

<syntaxhighlight lang="bash"># From host (won't work directly because we're not in labnet)
# But we can use docker exec from another container

# Quick test: use docker exec to reach Red from Red itself
docker exec red curl -s http://localhost | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Red Service</h1></pre>
'''Step 12: Start Blue container with CPU limit'''

<syntaxhighlight lang="bash">docker run -d \
--name blue \
--network labnet \
--ip 10.10.0.3 \
--cpus=0.5 \
-v ~/lab10-multicontainer/blue:/etc/caddy \
-v ~/lab10-multicontainer/blue:/usr/share/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--cpus=0.5</code>: cgroup CPU limit (maximum 50% of one CPU core)
** If CPU-intensive work is attempted, kernel will throttle it
* Other flags same as Red

'''Step 13: Verify both containers are running'''

<syntaxhighlight lang="bash">docker ps</syntaxhighlight>
'''Expected output:'''

<pre>CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 caddy "caddy run..." 20 seconds ago Up 18 seconds 80/tcp red
b7c8d9e0f1a2 caddy "caddy run..." 10 seconds ago Up 8 seconds 80/tcp blue</pre>
'''Step 14: Test container-to-container communication'''

<syntaxhighlight lang="bash"># From Red, ping Blue
docker exec red ping -c 2 10.10.0.3</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># From Red, curl Blue's website
docker exec red curl -s http://10.10.0.3 | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Blue Service</h1></pre>
Containers on the same custom network can communicate directly.


==== Part 3: Create Reverse Proxy (Purple) ====

'''Step 15: Create Purple's Caddyfile'''

This is the crucial piece—routing based on URL path (from Lab 9!)

<syntaxhighlight lang="bash">cat > ~/lab10-multicontainer/purple/Caddyfile << 'EOF'
:80 {
# Health check endpoint
handle /health {
respond "Purple Reverse Proxy - OK" 200
}

# Root path
handle / {
respond "Purple Reverse Proxy - Use /red/ or /blue/ paths" 200
}

# Route /red/* to red container (strip /red prefix)
handle_path /red/* {
reverse_proxy red:80
}

# Route /blue/* to blue container (strip /blue prefix)
handle_path /blue/* {
reverse_proxy blue:80
}

# Logging
log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Key points:'''

* <code>handle_path /red/*</code>: Matches any path starting with <code>/red/</code>
** <code>handle_path</code> strips the prefix before forwarding
** Client requests <code>/red/index.html</code> → Backend receives <code>/index.html</code>
* <code>reverse_proxy red:80</code>: Forward to container named "red" on port 80
** '''Using hostname "red", not IP!'''
** Docker's embedded DNS resolves "red" to 10.10.0.2
* Same for blue

'''Step 16: Start Purple reverse proxy'''

<syntaxhighlight lang="bash">docker run -d \
--name purple \
--network labnet \
--ip 10.10.0.10 \
-p 8080:80 \
-v ~/lab10-multicontainer/purple:/etc/caddy \
caddy</syntaxhighlight>
'''Flags explained:'''

* <code>--ip 10.10.0.10</code>: Purple gets IP 10.10.0.10 (different from Red/Blue)
* <code>-p 8080:80</code>: '''Port mapping''' (host port 8080 → container port 80)
** This is NAT (DNAT) from Lab 7!
** Traffic to <code>localhost:8080</code> on host gets forwarded to <code>10.10.0.10:80</code> in container


==== Part 4: Testing the Infrastructure ====

'''Step 17: Test health check'''

<syntaxhighlight lang="bash">curl http://localhost:8080/health</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - OK</pre>
This request:

# Reaches host's port 8080
# Docker's DNAT rule forwards to Purple (10.10.0.10:80)
# Purple's Caddy responds directly (no backend needed for /health)

'''Step 18: Test root path'''

<syntaxhighlight lang="bash">curl http://localhost:8080/</syntaxhighlight>
'''Expected output:'''

<pre>Purple Reverse Proxy - Use /red/ or /blue/ paths</pre>
'''Step 19: Test routing to Red'''

<syntaxhighlight lang="bash">curl http://localhost:8080/red/</syntaxhighlight>
'''Expected output:''' Red service HTML (with red background styling)

<syntaxhighlight lang="html"><!DOCTYPE html>
<html>
...
<h1>Red Service</h1>
<div>
Container: Red
IP: 10.10.0.2
...</syntaxhighlight>
'''What happened:'''

# Your curl → Host port 8080
# DNAT → Purple (10.10.0.10:80)
# Purple sees path <code>/red/</code>, strips <code>/red</code>, forwards <code>/</code> to <code>red:80</code>
# Purple's DNS resolves <code>red</code> to 10.10.0.2
# Request goes to Red (10.10.0.2:80)
# Red's Caddy serves <code>index.html</code>
# Response travels back through Purple to your curl

'''Step 20: Test routing to Blue'''

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/</syntaxhighlight>
'''Expected output:''' Blue service HTML (with blue background styling)

'''Step 21: Test with verbose output to see headers'''

<syntaxhighlight lang="bash">curl -v http://localhost:8080/red/ 2>&1 | grep -A10 "< HTTP"</syntaxhighlight>
'''Expected output:'''

<pre>< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Server: Caddy
< Date: Thu, 12 Dec 2024 11:30:00 GMT
< Content-Length: 687</pre>
'''Observe:''' <code>Server: Caddy</code> header (from Purple, acting as proxy)

'''Step 22: Test in browser'''

Open in your web browser:

* <code>http://localhost:8080/red/</code> → Should see red-styled page
* <code>http://localhost:8080/blue/</code> → Should see blue-styled page


==== Part 5: Inspect Resource Limits ====

'''Step 23: Check Red's memory limit'''

<syntaxhighlight lang="bash">docker inspect red --format='{{.HostConfig.Memory}}'</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
This is 256 MB in bytes (256 × 1024 × 1024 = 268435456).

'''Step 24: Check Blue's CPU limit'''

<syntaxhighlight lang="bash">docker inspect blue --format='{{.HostConfig.NanoCpus}}'</syntaxhighlight>
'''Expected output:'''

<pre>500000000</pre>
This is 0.5 CPU cores in nanocpus (0.5 × 10^9 = 500,000,000).

'''Step 25: View cgroup settings from the host'''

Get Red's main process PID:

<syntaxhighlight lang="bash">RED_PID=$(docker inspect red --format '{{.State.Pid}}')
echo "Red's PID: $RED_PID"</syntaxhighlight>
View memory limit in cgroup filesystem:

<syntaxhighlight lang="bash">cat /sys/fs/cgroup/memory/docker/$RED_PID/memory.limit_in_bytes</syntaxhighlight>
'''Expected output:'''

<pre>268435456</pre>
View Blue's CPU quota:

<syntaxhighlight lang="bash">BLUE_PID=$(docker inspect blue --format '{{.State.Pid}}')
cat /sys/fs/cgroup/cpu/docker/$BLUE_PID/cpu.cfs_quota_us</syntaxhighlight>
'''Expected output:'''

<pre>50000</pre>
'''Explanation:'''

* <code>cpu.cfs_period_us</code>: 100000 (default, 100ms period)
* <code>cpu.cfs_quota_us</code>: 50000 (50ms out of 100ms = 50% = 0.5 CPUs)

'''Connection to kernel concepts:'''

These cgroup files in <code>/sys/fs/cgroup/</code> are how the kernel enforces resource limits. Docker configures these files, and the kernel does the actual enforcement.


==== Part 6: Network Inspection ====

'''Step 26: Inspect labnet network showing all containers'''

<syntaxhighlight lang="bash">docker network inspect labnet --format='{{json .Containers}}' | python3 -m json.tool</syntaxhighlight>
'''Expected output:'''

<syntaxhighlight lang="json">{
"a1b2c3d4e5f6...": {
"Name": "red",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:02",
"IPv4Address": "10.10.0.2/24",
"IPv6Address": ""
},
"b7c8d9e0f1a2...": {
"Name": "blue",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:03",
"IPv4Address": "10.10.0.3/24",
"IPv6Address": ""
},
"f8e9c7b6d5a4...": {
"Name": "purple",
"EndpointID": "...",
"MacAddress": "02:42:0a:0a:00:0a",
"IPv4Address": "10.10.0.10/24",
"IPv6Address": ""
}
}</syntaxhighlight>
All three containers are on the labnet network with their assigned IPs.

'''Step 27: Test DNS resolution between containers'''

<syntaxhighlight lang="bash"># From Purple, resolve "red" hostname
docker exec purple nslookup red</syntaxhighlight>
'''Expected output:'''

<pre>Server: 127.0.0.11
Address: 127.0.0.11#53

Non-authoritative answer:
Name: red
Address: 10.10.0.2</pre>
'''Explanation:'''

* <code>127.0.0.11</code>: Docker's embedded DNS server (listening inside each container)
* DNS resolves container name "red" to IP 10.10.0.2

'''Step 28: Test connectivity using hostnames'''

<syntaxhighlight lang="bash"># Purple pings Red by hostname
docker exec purple ping -c 2 red</syntaxhighlight>
'''Expected:''' Success!

<syntaxhighlight lang="bash"># Purple curls Blue by hostname
docker exec purple curl -s http://blue | grep "<h1>"</syntaxhighlight>
'''Expected output:'''

<pre> <h1>Blue Service</h1></pre>

==== Part 7: Architecture Visualization ====

'''The architecture you built:'''

<pre> ┌─────────────────┐
│ Your Host │
│ (Port 8080) │
└────────┬────────┘
│
Port Mapping (NAT)
8080 → 80
│
┌────────▼────────┐
│ Purple Proxy │
│ 10.10.0.10:80 │
│ (Caddy) │
└────────┬────────┘
│
Docker Network: labnet
(Bridge: br-a1b2c3d4e5f6)
10.10.0.0/24
│
┌─────────┴──────────┐
│ │
┌────────▼────────┐ ┌───────▼─────────┐
│ Red Service │ │ Blue Service │
│ 10.10.0.2:80 │ │ 10.10.0.3:80 │
│ (Caddy) │ │ (Caddy) │
│ [mem: 256MB] │ │ [cpu: 0.5] │
└─────────────────┘ └─────────────────┘</pre>
'''Request flow for <code>curl http://localhost:8080/red/</code>:'''

<pre>1. Curl → localhost:8080 (your host)
2. Host's iptables DNAT rule → 10.10.0.10:80 (Purple)
3. Purple receives request to /red/
4. Purple's Caddy config: handle_path /red/* → reverse_proxy red:80
5. Purple strips /red prefix → request becomes /
6. Purple's DNS resolves "red" → 10.10.0.2
7. Purple → Red (10.10.0.2:80) GET /
8. Red's Caddy serves /usr/share/caddy/index.html
9. Response: Red → Purple → Host → Curl</pre>
'''Compare to Lab 7 and Lab 9:'''

* '''Lab 7''': You manually created bridges, veth pairs, assigned IPs, configured routes, set up NAT
* '''Lab 9''': You manually configured Caddy reverse proxy with path-based routing
* '''This exercise''': Docker automated all the networking, you just specified what you wanted


==== Part 8: Cleanup ====

'''Step 29: Stop all containers'''

<syntaxhighlight lang="bash">docker stop purple red blue</syntaxhighlight>
'''Step 30: Remove containers'''

<syntaxhighlight lang="bash">docker rm purple red blue</syntaxhighlight>
'''Step 31: Remove the network'''

<syntaxhighlight lang="bash">docker network rm labnet</syntaxhighlight>
'''Step 32: Verify cleanup'''

<syntaxhighlight lang="bash">docker ps -a
docker network ls</syntaxhighlight>
Only default networks (bridge, host, none) should remain.

'''Step 33: Verify host bridge removed'''

<syntaxhighlight lang="bash">ip link show | grep br-</syntaxhighlight>
The custom bridge (br-a1b2c3d4e5f6) should be gone. Only docker0 remains.


=== Deliverable E ===

Provide screenshots showing:

# Output of <code>docker network inspect labnet</code> showing all three containers with their IPs (before running curl tests)
# Output of <code>curl http://localhost:8080/health</code> (health check response)
# Output of <code>curl http://localhost:8080/red/</code> (Red service HTML) with visible red-styled content
# Output of <code>curl http://localhost:8080/blue/</code> (Blue service HTML) with visible blue-styled content
# Output of <code>docker inspect red --format='{{.HostConfig.Memory}}'</code> showing memory limit in bytes
# Output of <code>docker inspect blue --format='{{.HostConfig.NanoCpus}}'</code> showing CPU limit in nanocpus
# Output of <code>docker exec purple nslookup red</code> showing DNS resolution


== Reference: Docker Command Quick Guide ==

This section provides a quick reference for Docker commands introduced in this lab.


=== Container Lifecycle ===

<syntaxhighlight lang="bash"># Run container (create + start)
docker run [OPTIONS] IMAGE [COMMAND]
docker run -d nginx # Detached (background)
docker run -it ubuntu bash # Interactive with terminal
docker run --name mycontainer nginx # Assign name

# List containers
docker ps # Running only
docker ps -a # All (including stopped)
docker ps -q # Show only IDs (quiet)

# Start stopped container
docker start CONTAINER

# Stop running container
docker stop CONTAINER # Graceful (SIGTERM)
docker kill CONTAINER # Forceful (SIGKILL)

# Restart container
docker restart CONTAINER

# Remove container
docker rm CONTAINER # Must be stopped first
docker rm -f CONTAINER # Force remove (stop + remove)

# Execute command in running container
docker exec CONTAINER COMMAND
docker exec -it CONTAINER bash # Interactive shell

# View container logs
docker logs CONTAINER
docker logs -f CONTAINER # Follow (tail -f style)

# Inspect container (detailed JSON info)
docker inspect CONTAINER
docker inspect CONTAINER --format='{{.State.Status}}'</syntaxhighlight>

=== Image Management ===

<syntaxhighlight lang="bash"># List images
docker images
docker image ls

# Pull image from registry
docker pull IMAGE[:TAG]
docker pull nginx # Latest tag (default)
docker pull nginx:1.21 # Specific tag

# Remove image
docker rmi IMAGE
docker image rm IMAGE

# View image layers
docker history IMAGE

# Remove unused images
docker image prune # Dangling images
docker image prune -a # All unused images</syntaxhighlight>

=== Network Management ===

<syntaxhighlight lang="bash"># List networks
docker network ls

# Create network
docker network create NETWORK
docker network create --subnet=10.20.0.0/24 mynet

# Inspect network
docker network inspect NETWORK

# Connect container to network
docker network connect NETWORK CONTAINER

# Disconnect container from network
docker network disconnect NETWORK CONTAINER

# Remove network
docker network rm NETWORK

# Remove unused networks
docker network prune</syntaxhighlight>

=== Volume Management ===

<syntaxhighlight lang="bash"># List volumes
docker volume ls

# Create volume
docker volume create VOLUME

# Inspect volume
docker volume inspect VOLUME

# Remove volume
docker volume rm VOLUME

# Remove unused volumes
docker volume prune</syntaxhighlight>

=== Resource Management ===

<syntaxhighlight lang="bash"># CPU limits
--cpus=1.5 # Limit to 1.5 CPU cores
--cpu-shares=512 # Relative priority (default 1024)
--cpuset-cpus=0,1 # Pin to specific cores

# Memory limits
--memory=512m # Hard limit: 512 MB RAM
--memory=2g # Hard limit: 2 GB RAM
--memory-swap=1g # Total memory+swap
--memory-reservation=256m # Soft limit

# I/O limits
--device-read-bps=/dev/sda:10mb # Limit read bandwidth
--device-write-bps=/dev/sda:10mb # Limit write bandwidth

# Process limits
--pids-limit=100 # Max 100 processes</syntaxhighlight>

=== Inspection and Debugging ===

<syntaxhighlight lang="bash"># View resource usage stats
docker stats
docker stats CONTAINER # Specific container

# View processes in container
docker top CONTAINER

# View port mappings
docker port CONTAINER

# Copy files between host and container
docker cp CONTAINER:/path/to/file ./file # Container → Host
docker cp ./file CONTAINER:/path/to/file # Host → Container

# Stream events from Docker daemon
docker events

# Show disk usage
docker system df

# System-wide cleanup
docker system prune # Remove unused objects
docker system prune -a # Remove all unused objects
docker system prune -a --volumes # Include volumes</syntaxhighlight>

== Common Troubleshooting ==


=== Installation Issues ===

'''Problem:''' <code>docker --version</code> fails after installation

'''Solution:'''

<syntaxhighlight lang="bash"># Check if Docker daemon is running
sudo systemctl status docker

# If not running, start it
sudo systemctl start docker
sudo systemctl enable docker</syntaxhighlight>
'''Problem:''' "Cannot connect to the Docker daemon"

'''Cause:''' Docker daemon not running or permission issue

'''Solution:'''

<syntaxhighlight lang="bash"># Check daemon status
sudo systemctl status docker

# Check if your user is in docker group
groups | grep docker

# If not, add user and log out/in
sudo usermod -aG docker $USER</syntaxhighlight>

=== Permission Issues ===

'''Problem:''' "permission denied" when running docker commands

'''Solution:'''

<syntaxhighlight lang="bash"># Option 1: Add user to docker group (permanent)
sudo usermod -aG docker $USER
# Then log out and log back in

# Option 2: Use sudo (temporary)
sudo docker run hello-world</syntaxhighlight>
'''Problem:''' Files created by container are owned by root

'''Cause:''' Container runs as root (UID 0) by default

'''Solution:'''

<syntaxhighlight lang="bash"># Run container as specific user
docker run --user $(id -u):$(id -g) IMAGE

# Or use user namespaces (advanced)</syntaxhighlight>

=== Network Issues ===

'''Problem:''' Container can't access internet

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Test from container
docker exec CONTAINER ping -c 2 8.8.8.8

# Check Docker's NAT rules
sudo iptables -t nat -L -n | grep docker

# Check IP forwarding
sysctl net.ipv4.ip_forward</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Enable IP forwarding if disabled
sudo sysctl -w net.ipv4.ip_forward=1

# Restart Docker daemon
sudo systemctl restart docker</syntaxhighlight>
'''Problem:''' Containers on custom network can't communicate

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check network exists
docker network ls

# Check containers are on same network
docker network inspect NETWORK

# Test connectivity
docker exec CONTAINER1 ping CONTAINER2_IP</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Ensure both containers on same network
docker network connect NETWORK CONTAINER</syntaxhighlight>
'''Problem:''' Port mapping not working (<code>-p</code> flag)

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check port is actually mapped
docker port CONTAINER

# Check if host port is already in use
sudo ss -tulpn | grep :8080</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># If port in use, use different host port
docker run -p 8081:80 nginx

# Or stop the conflicting process
sudo fuser -k 8080/tcp</syntaxhighlight>

=== Storage Issues ===

'''Problem:''' "No space left on device"

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check Docker disk usage
docker system df

# Check host disk space
df -h /var/lib/docker</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Remove unused objects
docker system prune -a

# Remove specific old images
docker images
docker rmi IMAGE_ID</syntaxhighlight>
'''Problem:''' Changes in bind mount not visible in container

'''Cause:''' Path doesn't exist or wrong path specified

'''Solution:'''

<syntaxhighlight lang="bash"># Verify path exists on host
ls -la /path/to/host/directory

# Use absolute paths
docker run -v /absolute/path:/container/path IMAGE

# Or use $PWD for current directory
docker run -v $PWD/relative/path:/container/path IMAGE</syntaxhighlight>

=== Resource Limit Issues ===

'''Problem:''' Container killed unexpectedly

'''Diagnostics:'''

<syntaxhighlight lang="bash"># Check container exit code
docker inspect CONTAINER --format='{{.State.ExitCode}}'
# Exit code 137 = killed (often OOM)

# Check logs
docker logs CONTAINER</syntaxhighlight>
'''Solution:'''

<syntaxhighlight lang="bash"># Increase memory limit
docker run --memory=1g IMAGE

# Or run without memory limit (default)
docker run IMAGE</syntaxhighlight>
'''Problem:''' Container using too much CPU

'''Solution:'''

<syntaxhighlight lang="bash"># Limit CPU usage
docker run --cpus=0.5 IMAGE

# Check what's consuming CPU
docker exec CONTAINER top</syntaxhighlight>

== Next Steps: Dockerfile and Docker Compose ==

Congratulations! You've mastered the fundamental OS concepts behind containers:

* '''Namespaces''' provide isolation (network, PID, mount, UTS, IPC, user, cgroup)
* '''cgroups''' enforce resource limits (CPU, memory, I/O)
* '''OverlayFS''' provides efficient layered filesystems
* '''Bridges and veth pairs''' connect containers (same as Lab 7!)
* '''Volumes''' persist data beyond container lifecycles

However, you've been using '''pre-built images''' and running containers with long <code>docker run</code> commands. In production environments, you need:

# '''Custom images''' tailored to your applications
# '''Reproducible builds''' that can be version-controlled
# '''Multi-container orchestration''' with coordinated startup and networking

This is where '''Dockerfile''' and '''Docker Compose''' come in.


=== Dockerfile: Building Custom Images ===

Instead of starting from a base image and manually installing packages, you define your application's environment in a <code>Dockerfile</code>:

<syntaxhighlight lang="dockerfile"># Start from Ubuntu base image
FROM ubuntu:22.04

# Install dependencies
RUN apt-get update && apt-get install -y \
python3 \
python3-pip \
&& rm -rf /var/lib/apt/lists/*

# Copy application code
COPY app.py /app/
COPY requirements.txt /app/

# Install Python dependencies
WORKDIR /app
RUN pip3 install -r requirements.txt

# Expose port
EXPOSE 8000

# Define startup command
CMD ["python3", "app.py"]</syntaxhighlight>
'''Build the image:'''

<syntaxhighlight lang="bash">docker build -t myapp:1.0 .</syntaxhighlight>
'''Run containers from your custom image:'''

<syntaxhighlight lang="bash">docker run -d -p 8000:8000 myapp:1.0</syntaxhighlight>
'''Benefits:'''

* '''Reproducibility''': Same Dockerfile always builds identical image
* '''Version control''': Dockerfile lives in git alongside code
* '''Documentation''': Dockerfile explicitly documents dependencies and setup
* '''Automation''': CI/CD pipelines can build images automatically

'''Common Dockerfile instructions:'''

* <code>FROM</code>: Base image to start from
* <code>RUN</code>: Execute command during build (install packages, etc.)
* <code>COPY</code> / <code>ADD</code>: Copy files from host into image
* <code>WORKDIR</code>: Set working directory
* <code>ENV</code>: Set environment variables
* <code>EXPOSE</code>: Document which ports the application uses
* <code>CMD</code>: Default command to run when container starts
* <code>ENTRYPOINT</code>: Configure container as executable

'''Best practices:'''

* Use specific image tags (not <code>latest</code>)
* Minimize layers (combine <code>RUN</code> commands)
* Leverage build cache (order instructions from least to most frequently changing)
* Use <code>.dockerignore</code> (like <code>.gitignore</code> for Docker builds)
* Don't run as root (use <code>USER</code> instruction)
* Multi-stage builds for smaller images


=== Docker Compose: Multi-Container Orchestration ===

Instead of running multiple <code>docker run</code> commands with complex options, define your entire infrastructure in a <code>docker-compose.yml</code> file:

<syntaxhighlight lang="yaml">version: '3.8'

services:
# Purple reverse proxy
purple:
image: caddy
ports:
- "8080:80"
volumes:
- ./purple:/etc/caddy
networks:
labnet:
ipv4_address: 10.10.0.10
depends_on:
- red
- blue

# Red backend
red:
image: caddy
volumes:
- ./red:/etc/caddy
- ./red:/usr/share/caddy
networks:
labnet:
ipv4_address: 10.10.0.2
deploy:
resources:
limits:
memory: 256M

# Blue backend
blue:
image: caddy
volumes:
- ./blue:/etc/caddy
- ./blue:/usr/share/caddy
networks:
labnet:
ipv4_address: 10.10.0.3
deploy:
resources:
limits:
cpus: '0.5'

networks:
labnet:
driver: bridge
ipam:
config:
- subnet: 10.10.0.0/24</syntaxhighlight>
'''Start entire infrastructure:'''

<syntaxhighlight lang="bash">docker compose up</syntaxhighlight>
Or in detached mode:

<syntaxhighlight lang="bash">docker compose up -d</syntaxhighlight>
'''Stop everything:'''

<syntaxhighlight lang="bash">docker compose down</syntaxhighlight>
'''View logs:'''

<syntaxhighlight lang="bash">docker compose logs -f</syntaxhighlight>
'''Benefits:'''

* '''Declarative''': Describe desired state, not imperative commands
* '''Single source of truth''': One file defines entire application
* '''Easy to share''': Colleagues can run <code>docker compose up</code> and get identical environment
* '''Development/production parity''': Same compose file works everywhere
* '''Automatic networking''': Compose creates network and DNS automatically

'''This is the production-ready way to deploy multi-container applications.'''

'''Further learning:'''

* '''Dockerfile''': Learn advanced instructions, multi-stage builds, build arguments
* '''Docker Compose''': Learn service dependencies, health checks, scaling
* '''Docker Swarm''': Docker's built-in orchestration for multi-host deployments
* '''Kubernetes''': Industry-standard container orchestration platform
* '''Container registries''': Push images to Docker Hub, GitHub Container Registry, or private registries
* '''Security''': Image scanning, rootless Docker, seccomp profiles, AppArmor

These topics build on the solid foundation you've established in this lab. You now understand what containers actually are at the OS level—the rest is learning tools that make containers easier to build and deploy.


== Deliverables and Assessment ==

Submit a single PDF document containing all deliverables from Exercises A through E, organized with clear section headers matching the exercise labels.

'''Required deliverables:'''

* '''Deliverable A''': Installation verification (screenshots)
* '''Deliverable B''': Hello World and namespace inspection (screenshots)
* '''Deliverable C''': Fedora exploration (screenshots)
* '''Deliverable D''': Persistent storage (screenshots)
* '''Deliverable E''': Multi-container infrastructure (screenshots)


== Additional Resources ==

This lab introduced containerization using Docker, demonstrating how Linux kernel features (namespaces, cgroups, OverlayFS) are composed to create isolated application environments. You've seen that Docker is not magic—it's sophisticated automation of kernel primitives you already understand from previous labs.


=== For Further Study ===

'''Container Internals:'''

* Deep dive into runc (the OCI runtime that Docker uses)
* Understanding containerd (container runtime layer)
* Linux capabilities and security contexts
* AppArmor and SELinux profiles for containers
* User namespaces and rootless containers
* Seccomp profiles for system call filtering

'''Dockerfile Best Practices:'''

* Multi-stage builds for smaller images
* Build cache optimization strategies
* Layer ordering for efficient rebuilds
* .dockerignore for excluding files
* Security scanning with Trivy or Clair
* Distroless and minimal base images

'''Docker Compose Advanced:'''

* Service dependencies with health checks
* Environment-specific overrides
* Secrets management
* Multiple compose files (base + overrides)
* Named volumes vs bind mounts
* Integration testing with compose

'''Container Orchestration:'''

* Kubernetes architecture and concepts
* kubectl basics
* Pods, Services, Deployments, ConfigMaps
* Kubernetes networking (CNI plugins)
* Helm charts for package management
* Service mesh (Istio, Linkerd)

'''Container Networking Deep Dive:'''

* Bridge vs host vs macvlan networking
* Overlay networks for multi-host communication
* Network plugins and CNI specification
* Load balancing strategies
* Service discovery patterns
* Network policies and segmentation

'''Security:'''

* Container escape techniques and mitigations
* Image vulnerability scanning
* Runtime security monitoring (Falco)
* Least privilege principles
* Supply chain security
* Harbor for secure image registry

'''Performance:'''

* Container resource tuning
* Storage drivers (overlay2, btrfs, zfs)
* Network performance optimization
* Monitoring with Prometheus and Grafana
* Distributed tracing with Jaeger

'''Production Operations:'''

* Logging strategies (centralized logging)
* Health checks and readiness probes
* Rolling updates and blue-green deployments
* Backup and disaster recovery
* CI/CD integration (Jenkins, GitLab CI)
* Container registries (private, public)


=== Relevant Manual Pages ===

<syntaxhighlight lang="bash">man 7 namespaces # Linux namespaces overview
man 7 cgroups # Control groups overview
man 2 unshare # Create namespaces
man 2 setns # Enter existing namespace
man 8 nsenter # Run program in namespace
man 1 docker # Docker CLI reference
man 1 docker-run # docker run reference
man 1 docker-compose # Docker Compose reference</syntaxhighlight>

=== Online Resources ===

'''Official Documentation:'''

* [https://docs.docker.com/ Docker Documentation] - Comprehensive official docs
* [https://hub.docker.com/ Docker Hub] - Public image registry
* [https://opencontainers.org/ OCI Specification] - Open Container Initiative standards
* [https://containerd.io/docs/ containerd Documentation] - Container runtime

'''Tutorials and Guides:'''

* [https://docker-curriculum.com/ Docker Curriculum] - Beginner-friendly tutorial
* [https://labs.play-with-docker.com/ Play with Docker] - Free interactive playground
* [https://kubernetes.io/docs/ Kubernetes Documentation] - K8s official docs
* [https://docs.docker.com/develop/develop-images/dockerfile_best-practices/ Dockerfile Best Practices]

'''Deep Dives:'''

* [https://lwn.net/Articles/531114/ Understanding Namespaces (LWN)] - Series on Linux namespaces
* [https://jvns.ca/blog/2016/10/10/what-even-is-a-container/ How Containers Work] - Excellent blog post by Julia Evans
* [https://sysdig.com/blog/dockerfile-best-practices/ Container Security Best Practices] - Security-focused guide

'''Community:'''

* [https://forums.docker.com/ Docker Forums] - Community support
* [https://stackoverflow.com/questions/tagged/docker Stack Overflow - Docker Tag]
* [https://reddit.com/r/docker Reddit r/docker]
* [https://slack.cncf.io/ CNCF Slack] - Cloud Native Computing Foundation community

'''Practice Environments:'''

* [https://www.katacoda.com/ Katacoda] - Interactive Docker and Kubernetes scenarios
* [https://labs.play-with-k8s.com/ Play with Kubernetes] - K8s playground
* [https://killercoda.com/ KillerCoda] - Interactive learning scenarios

Operating Systems

2025-12-12T14:50:28Z

Vserbu: /* Lab Sessions */

OS Lab 9 - Application Protocols: DNS, SSH, HTTP(S)

2025-12-05T15:10:10Z

Vserbu: Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Understand core internet infrastructure: well-known ports, DNS hierarchy, and t...

== Objectives ==

Upon completion of this lab, you will be able to:

* Understand core internet infrastructure: well-known ports, DNS hierarchy, and the roles of authoritative vs. recursive DNS servers.
* Use DNS tools (<code>dig</code>, <code>nslookup</code>, <code>host</code>) to query records and analyze responses, including TTLs and caching behavior.
* Configure secure SSH access using Ed25519 keys and explain SSH’s TOFU model compared with certificate-based PKI.
* Build and route HTTP(S) services using a reverse proxy, and understand why this pattern underlies modern cloud architectures.
* Diagnose common application-layer connectivity issues using protocol-specific debugging techniques.


== Introduction ==


=== The Journey Through the Network Stack ===

In Labs 7 and 8, we systematically constructed the entire networking stack from the physical layer upward:

* '''Lab 7 (Network Infrastructure)''': We built the foundational plumbing—network interfaces, MAC addresses, IP addressing, routing tables, network bridges, and the mechanisms that allow one machine to physically reach another across networks. We demonstrated how the kernel routes packets from source to destination based on Ethernet and Layer 3 IP addressing.
* '''Lab 8 (Transport and Security)''': We ascended to the transport layer, introducing the critical concept of '''ports''' to enable process-to-process communication. We explored the fundamental trade-offs between UDP's connectionless simplicity and TCP's reliable, connection-oriented delivery. Most importantly, we implemented Transport Layer Security (TLS) using Public Key Infrastructure (PKI) to protect data in transit from eavesdropping and tampering.

We now reach the pinnacle of the network stack: called the Application Layer in the TCP/IP model. This is where protocols transition from answering "how do we reliably deliver data between processes?" to addressing "what should we do with this data and how should applications interact?"


=== The Application Layer ===

Consider what you actually accomplish with computers in daily practice. You do not consciously think about TCP sequence numbers, IP routing algorithms, or TLS cipher suites. Instead, you engage in high-level activities:

* You type a domain name (e.g., "example.com") and a website appears instantaneously (DNS + HTTP)
* You connect to a remote server to execute commands securely (SSH)
* You upload files, stream videos, send API requests, interact with cloud services (predominantly HTTP/HTTPS)

The application layer is where networking infrastructure becomes visible as useful services. These are the protocols that system administrators, DevOps engineers, and software developers interact with constantly. While hundreds of application protocols exist, three protocols dominate modern networking:

# '''DNS (Port 53)''': The distributed directory service that answers "How do I find the IP address for this domain name?"
# '''SSH (Port 22)''': The secure remote access protocol that answers "How do I securely administer remote systems?"
# '''HTTP/HTTPS (Ports 80/443)''': The hypertext transfer protocol that has evolved far beyond web browsing to become the answer to "How do I communicate application data?" for nearly everything.


=== The Complete Network Request Journey ===

By the end of this lab, you will understand the complete, end-to-end journey of a modern web request. When you type <code>https://api.example.com/users</code> into your browser, the following sequence occurs:

# '''DNS Resolution (This lab)''': Your system queries DNS to resolve <code>api.example.com</code> to an IP address (e.g., 203.0.113.50)
# '''Routing (Lab 7)''': The kernel consults routing tables to determine the next hop toward that IP address
# '''TCP Connection (Lab 8)''': Your system establishes a three-way handshake to create a reliable TCP connection to port 443 at that IP address
# '''TLS Handshake (Lab 8)''': The client and server perform a TLS handshake, establishing an encrypted tunnel using certificates to verify the server's identity
# '''HTTP Request (This lab)''': Your browser sends an HTTP GET request to the <code>/users</code> path over the encrypted connection
# '''Reverse Proxy Routing (This lab)''': A reverse proxy on the server side examines the request path and routes it to the appropriate backend service
# '''Response Journey''': The response flows back through all these layers—HTTP response, TLS encryption, TCP segments, IP packets, Ethernet frames—until it reaches your browser


== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console.

'''Network Topology''': This lab builds upon the network namespace topology established in Lab 8. You should have:

* '''Red namespace''': Simulated host with IP address 10.0.0.1/24
* '''Blue namespace''': Simulated host with IP address 10.0.0.2/24
* '''Host system''': Bridge interface (br0) connecting the namespaces
* Full bidirectional connectivity verified in Lab 8

If you did not complete Lab 8 or your topology has been reset, you will need to recreate it following Lab 8's setup instructions before proceeding.


=== Required Packages ===

The following packages must be installed. Run these commands on your host system:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y openssh-server openssh-client dnsutils bind9-dnsutils \
caddy curl net-tools</syntaxhighlight>
Package descriptions:

* <code>openssh-server</code>: OpenSSH server daemon for accepting SSH connections
* <code>openssh-client</code>: OpenSSH client tools (ssh, scp, sftp) for initiating connections
* <code>dnsutils</code>: DNS client utilities including <code>dig</code> and <code>nslookup</code>
* <code>bind9-dnsutils</code>: Additional DNS diagnostic tools including <code>host</code>
* <code>caddy</code>: Modern web server with automatic HTTPS and simple configuration syntax
* <code>curl</code>: Command-line HTTP client for testing and debugging
* <code>net-tools</code>: Legacy networking tools (netstat, ifconfig) for compatibility


=== Knowledge Prerequisites ===

You should be familiar with:

'''From Lab 7 (Network Fundamentals)''':

* Network interfaces, IP addresses, subnet masks, and CIDR notation
* Routing tables and default gateways
* Network namespaces and virtual ethernet pairs
* Bridge devices and how they connect network segments

'''From Lab 8 (Transport and Security)''':

* TCP and UDP transport protocols
* Port numbers and socket addresses (IP:PORT)
* TLS encryption and certificate-based authentication
* The Public Key Infrastructure (PKI) trust model
* Basic hostname resolution using <code>/etc/hosts</code>

'''General Linux Skills''':

* Command-line text manipulation (grep, awk, sed, cut)
* Process management (starting, stopping, viewing processes)
* File editing with text editors (nano, vim, or your preference)
* Basic Bash scripting (variables, loops, conditionals)

You should also understand:

* The client-server model of network communication
* What an IP address represents and how packets are routed between networks
* The concept of a socket as the combination of IP address and port number
* Basic cryptographic concepts (public/private keys, certificates)


== Theoretical Background ==


=== The Transport Layer Recap ===

Before diving into application protocols, let us briefly revisit why the transport layer exists and what problem it solves. This context is essential for understanding well-known ports and application protocol design.

'''The Fundamental Problem''': An IP address identifies a machine on the network, but machines do not communicate with machines. '''Processes''' (running programs) communicate with processes. When a packet arrives at your machine's IP address, the kernel must determine which of potentially hundreds of running processes should receive that packet.

'''The Solution''': The transport layer introduces '''port numbers'''—16-bit unsigned integers (range 0-65535) that identify specific communication endpoints. When combined with an IP address, a port creates a unique '''socket address''' (written as IP:PORT, e.g., 192.168.1.50:443) that identifies a specific process on a specific machine.

A complete connection is identified by a '''five-tuple''':

# Source IP address
# Source port
# Destination IP address
# Destination port
# Protocol (TCP or UDP)

This five-tuple uniquely identifies a communication channel. For example:

* Client: 192.168.1.50:54321 → Server: 203.0.113.10:443 (HTTPS connection)
* Client: 10.0.0.1:35678 → Server: 10.0.0.2:22 (SSH connection)

With this foundation established, we can now explore how standardized port numbers enable service discovery at internet scale.


=== Well-Known Ports ===


==== The Problem: Service Discovery Without Coordination ====

Consider a scenario where you want to connect to a web server running at IP address <code>10.0.0.3</code>. You know the machine's network address, but you face a critical problem: '''Which port is the web server listening on?'''

The server could be bound to any of 65,535 possible port numbers:

* Port 80? (Traditional HTTP)
* Port 8080? (Alternative HTTP)
* Port 3000? (Common development port)
* Port 9000? (Arbitrary choice)
* Some completely random port like 47281?

Without knowing the correct port, you cannot establish a connection. It is analogous to knowing someone's street address but not their apartment number in a massive building with 65,535 apartments.

You could attempt to connect to all 65,535 ports sequentially (this is precisely what port scanning tools like <code>nmap</code> do), but this approach is:

* Extremely slow (trying all ports could take minutes or hours)
* Inefficient (wastes network bandwidth and computational resources)
* Potentially suspicious (may trigger intrusion detection systems)
* Impractical for everyday use (users expect instant connections)

There must be a superior solution.


==== The Solution: Standardized Port Assignments ====

The early architects of the internet solved this problem through an elegantly simple mechanism: '''social convention'''. The Internet Assigned Numbers Authority (IANA) maintains an official registry of port number assignments, and the community agrees to follow these standards.

This is not a technical enforcement mechanism—there is no kernel code that prevents you from running an SSH server on port 8080 or an HTTP server on port 22. Instead, it is a '''social contract''': we collectively agree that certain services will use certain ports, making the internet predictable and functional.


==== Port Number Space Division ====

The IANA divides the port number space into three categories:

'''1. Well-Known Ports (0-1023)'''

These ports are reserved for standard, widely-used services. Key characteristics:

* Officially registered with IANA for specific protocols
* Binding to these ports requires elevated privileges (root/administrator) on Unix-like systems
* This privilege requirement is a security feature: it prevents normal users from impersonating critical services
* Examples: HTTP (80), HTTPS (443), SSH (22), DNS (53), SMTP (25)

The privilege requirement exists because if any user could bind to port 80, they could impersonate a web server and potentially trick other programs or users into trusting them.

'''2. Registered Ports (1024-49151)'''

These ports can be registered with IANA for specific services, but enforcement is less strict. Characteristics:

* No special privileges required to bind
* Software vendors often register ports for their applications
* Examples: MySQL (3306), PostgreSQL (5432), MongoDB (27017), Redis (6379)
* Applications can use these ports without requiring root access

'''3. Dynamic/Private/Ephemeral Ports (49152-65535)'''

These ports are used for temporary client-side connections. Characteristics:

* Never registered for permanent services
* Assigned automatically by the operating system when a client initiates an outbound connection
* The client doesn't choose these ports explicitly
* Used briefly for the duration of a connection, then released back to the pool

When your web browser connects to a server, it might use local address <code>192.168.1.50:52341</code> (your machine + random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server + standard HTTPS port).


==== The Social Contract in Practice ====

When a server administrator configures a service, they '''listen on the well-known port''' for that service type. Clients, in turn, '''assume''' servers use these standard ports. This mutual agreement eliminates the need for explicit coordination.

'''Example 1: SSH Connection'''

When you execute:

<syntaxhighlight lang="bash">ssh admin@server.example.com</syntaxhighlight>
The SSH client automatically attempts to connect to port 22. You do not need to specify the port. The client assumes the server follows the convention. Under the hood, this command is equivalent to:

<syntaxhighlight lang="bash">ssh -p 22 admin@server.example.com</syntaxhighlight>
The <code>-p 22</code> is implicit because port 22 is the well-known port for SSH.

'''Example 2: Web Browsing'''

When you enter a URL in your browser:

<pre>http://example.com</pre>
Your browser automatically connects to port 80. Similarly, for:

<pre>https://example.com</pre>
Your browser connects to port 443. These behaviors are hardcoded into HTTP client software based on the URL scheme.

'''Breaking the Convention'''

You are not technically required to follow these conventions. You can run an SSH server on port 8022, a web server on port 3000, or DNS on port 5353. However, breaking conventions creates friction—clients need explicit instructions:

<syntaxhighlight lang="bash"># Non-standard SSH port requires explicit specification
ssh -p 8022 admin@server.example.com

# Non-standard HTTP port must be included in URL
curl http://example.com:3000</syntaxhighlight>
'''Analogy''': Well-known ports function like standardized electrical outlets. In Europe, you expect 220V AC outlets with a specific two-prong configuration. You can plug in any device without checking each outlet—you trust the convention. Similarly, you can connect to any SSH server without checking its port—you trust it will be on port 22.

'''Critical Ports'''

As a system administrator or developer, you will usually interact with these port numbers:

* '''Port 20/21''': FTP (File Transfer Protocol) - Legacy, rarely used today
* '''Port 22''': SSH (Secure Shell) - Remote system access
* '''Port 23''': Telnet - Legacy insecure remote access (NEVER USE)
* '''Port 25''': SMTP (Simple Mail Transfer Protocol) - Email sending
* '''Port 53''': DNS (Domain Name System) - Name resolution
* '''Port 80''': HTTP (Hypertext Transfer Protocol) - Web traffic unencrypted
* '''Port 110''': POP3 (Post Office Protocol) - Email retrieval (legacy)
* '''Port 143''': IMAP (Internet Message Access Protocol) - Modern email retrieval
* '''Port 443''': HTTPS (HTTP Secure) - Encrypted web traffic
* '''Port 3306''': MySQL database server
* '''Port 5432''': PostgreSQL database server
* '''Port 6379''': Redis in-memory database
* '''Port 8080''': Alternative HTTP port (often used for development)

This social contract—standardized port numbers—is a foundational element that makes the internet function at global scale. It exemplifies how simple conventions can solve complex coordination problems.


=== Domain Name System (DNS) ===

The human-computer impedance mismatch is a fundamental challenge in computing: humans prefer memorable, meaningful names, while computers require numerical addresses. The Domain Name System (DNS) bridges this gap by providing a distributed, hierarchical database that maps human-readable domain names to machine-usable IP addresses (and other information).


==== Human Memory vs. Computer Addressing ====

IP addresses are the actual addressing mechanism for network communication. When your computer needs to send packets to a destination, it must know that destination's IP address. However, IP addresses present several problems for human users:

'''1. Memorization Difficulty'''

IPv4 addresses like <code>172.217.14.206</code> are difficult for humans to remember and type accurately. IPv6 addresses like <code>2607:f8b0:4004:c07::64</code> are even worse. While you might remember your own phone number, remembering hundreds of IP addresses for services you use is impractical.

'''2. Instability and Change'''

IP addresses can change due to:

* Infrastructure migrations (moving servers between data centers)
* Load balancing requirements (distributing traffic across multiple servers)
* Failover scenarios (switching to backup servers during outages)
* Dynamic allocation (DHCP assigns different IPs over time)

If users memorized IP addresses, every infrastructure change would break their connections.

'''3. Lack of Semantic Meaning'''

An IP address like <code>198.51.100.42</code> conveys no information about what service it provides or which organization operates it. The name <code>store.example.com</code> immediately suggests it's a commercial store operated by Example Corporation.

'''4. Service Multiplexing'''

A single IP address can host multiple services (using different ports) or multiple websites (using HTTP virtual hosting). The domain name helps identify which specific service the user wants.

The Solution: Domain Name System

DNS solves these problems by creating a globally distributed, hierarchical naming system that maps domain names to IP addresses and other resource records.

'''Historical Context''': Before DNS, the internet used a centralized hosts file (<code>/etc/hosts</code> on Unix systems) maintained by the Network Information Center (NIC) at Stanford Research Institute. Administrators would request IP-to-hostname mappings, and NIC would periodically distribute an updated hosts file to all connected systems. This approach did not scale beyond a few thousand hosts.

In 1983, Paul Mockapetris designed the Domain Name System (RFC 882 and RFC 883, later superseded by RFC 1034 and RFC 1035), which has remained the foundation of internet naming for over 40 years.


==== DNS Hierarchy: Organizing the Global Namespace ====

DNS organizes domain names in a hierarchical tree structure, reading from right to left:

<pre>www.engineering.example.com.
| | | |
| | | └── Root (empty label)
| | └────────── Top-Level Domain (TLD)
| └───────────────────── Second-Level Domain (SLD)
└───────────────────────────── Subdomain(s)</pre>
'''The Root Domain (".")'''

At the top of the hierarchy is the root domain, represented by an empty label. Fully qualified domain names (FQDNs) technically end with a dot: <code>example.com.</code> The trailing dot is usually omitted in practice, but it represents the root.

There are 13 root name server systems (labeled A through M: a.root-servers.net through m.root-servers.net) operated by different organizations worldwide. These are the authoritative source for information about top-level domains.

'''Top-Level Domains (TLDs)'''

TLDs are the highest level of the DNS hierarchy below the root. Categories include:

* '''Generic TLDs (gTLDs)''': .com, .org, .net, .edu, .gov, .mil, .int
* '''Country-Code TLDs (ccTLDs)''': .us (United States), .uk (United Kingdom), .jp (Japan), .de (Germany)
* '''New gTLDs''': .app, .dev, .tech, .cloud, .blog, etc. (thousands added since 2013)

Each TLD is managed by a registry organization. For example, VeriSign operates the .com and .net TLDs, while Educause operates .edu.

'''Second-Level Domains (SLDs)'''

These are the domains that organizations register: <code>example.com</code>, <code>github.com</code>, <code>mit.edu</code>. You register these through domain registrars, who interface with the TLD registries.

'''Subdomains'''

Domain owners can create arbitrary subdomains: <code>www.example.com</code>, <code>mail.example.com</code>, <code>api.v2.example.com</code>. Subdomains do not require separate registration—the owner of the parent domain controls all subdomains.

DNS Servers: Authoritative vs. Recursive

Two fundamentally different types of DNS servers perform distinct roles in the DNS infrastructure:

'''Authoritative DNS Servers'''

Authoritative servers are the definitive source of truth for a specific zone (portion of the DNS namespace). Characteristics:

* '''Responsibility''': Provide answers for domains they have explicit authority over
* '''Data Source''': Return information directly from their configured zone files
* '''Behavior''': Only answer queries for domains in their zones; refer queries elsewhere for other domains
* '''Operation''': Typically operated by domain owners or their DNS providers
* '''Caching''': Do not cache responses for other domains
* '''Example''': If you own <code>example.com</code>, your authoritative servers know the IP addresses for <code>www.example.com</code>, <code>mail.example.com</code>, etc.

When you configure DNS records for your domain through your registrar or DNS provider, you are updating authoritative servers.

'''Recursive DNS Resolvers (Recursive Resolvers)'''

Recursive resolvers perform the DNS resolution process on behalf of clients. Characteristics:

* '''Responsibility''': Answer any DNS query by recursively querying authoritative servers
* '''Data Source''': Cache responses and query authoritative servers when cache misses occur
* '''Behavior''': Accept any query and traverse the DNS hierarchy to find answers
* '''Operation''': Typically provided by ISPs, corporations, or public DNS services (Google Public DNS 8.8.8.8, Cloudflare 1.1.1.1)
* '''Caching''': Extensively cache responses to improve performance and reduce load
* '''Client-Facing''': This is the type of server that end-user devices query

When your computer performs a DNS lookup, it queries a recursive resolver, which then does the work of finding the answer.

'''Critical Distinction'''

This distinction is fundamental:

* '''Authoritative servers''': "I have authority over example.com, and I can definitively tell you that [http://www.example.com www.example.com] is 203.0.113.50"
* '''Recursive resolvers''': "I don't know the answer to your query, but I'll traverse the DNS hierarchy to find an authoritative server that does know, then give you the answer"

'''Analogy''': An authoritative DNS server is like a property owner who knows everything about their own house. A recursive resolver is like a GPS navigation system that can find directions to any address by consulting various maps and data sources.


==== DNS Resolution Process: Following the Hierarchy ====

When you type <code>www.example.com</code> in your browser and press Enter, a complex resolution process occurs behind the scenes. Let us trace this process step by step.

'''Scenario''': Your computer needs to resolve <code>www.example.com</code> to an IP address. Your system is configured to use the recursive resolver at 1.1.1.1 (Cloudflare's public DNS).

'''Step 1: Check Local Cache'''

Your operating system maintains a local DNS cache. If <code>www.example.com</code> was recently resolved and the TTL hasn't expired, the cached answer is returned immediately (typically in microseconds). No network query is needed.

If the cache contains no valid entry, proceed to Step 2.

'''Step 2: Query Recursive Resolver'''

Your computer sends a DNS query to its configured recursive resolver (1.1.1.1):

<pre>Query: What is the IP address for www.example.com?</pre>
The recursive resolver checks its own cache. If it has a recent answer, it returns immediately. If not, it begins the recursive resolution process.

'''Step 3: Query Root Servers'''

The recursive resolver queries one of the 13 root name servers:

<pre>Resolver → Root Server: What is the IP address for www.example.com?</pre>
The root server does not know the specific answer but knows which servers are authoritative for the .com TLD:

<pre>Root → Resolver: I don't know about www.example.com specifically,
but you can ask the .com TLD servers. Here are their addresses:
- a.gtld-servers.net (192.5.6.30)
- b.gtld-servers.net (192.33.14.30)
[and others...]</pre>
This is called a '''referral'''—the root server refers the resolver to servers that are more specific.

'''Step 4: Query TLD Servers'''

The resolver queries one of the .com TLD servers:

<pre>Resolver → .com TLD Server: What is the IP address for www.example.com?</pre>
The TLD server knows which name servers are authoritative for example.com:

<pre>.com TLD → Resolver: I don't know about www.example.com specifically,
but the authoritative servers for example.com are:
- ns1.example.com (198.51.100.1)
- ns2.example.com (198.51.100.2)</pre>
Another referral, this time to the authoritative servers for the domain.

'''Step 5: Query Authoritative Servers'''

The resolver queries example.com's authoritative name server:

<pre>Resolver → ns1.example.com: What is the IP address for www.example.com?</pre>
This server has definitive authority over example.com and provides the answer:

<pre>ns1.example.com → Resolver: www.example.com is 203.0.113.50
(TTL: 3600 seconds)</pre>
'''Step 6: Return Answer to Client'''

The recursive resolver returns the answer to your computer:

<pre>Resolver → Your Computer: www.example.com is 203.0.113.50</pre>
'''Step 7: Cache at Multiple Levels'''

The answer is cached:

* Your operating system caches the result (OS-level cache)
* Your browser may have its own cache (application-level cache)
* The recursive resolver caches the result (resolver cache)

Future queries for <code>www.example.com</code> within the TTL period (3600 seconds = 1 hour in this example) will be answered from cache without repeating the full resolution process.


==== DNS Record Types ====

DNS stores more than just IP addresses. Different record types serve different purposes:

'''A Record (Address Record)'''

Maps a domain name to an IPv4 address.

<pre>www.example.com. IN A 203.0.113.50</pre>
This is the most common record type. When you browse to a website, your browser requests the A record to find the server's IPv4 address.

'''AAAA Record (IPv6 Address Record)'''

Maps a domain name to an IPv6 address.

<pre>www.example.com. IN AAAA 2001:db8::1</pre>
Pronounced "quad-A record." As IPv6 adoption increases, these records are becoming more common.

'''CNAME Record (Canonical Name Record)'''

Creates an alias from one domain name to another. The resolver follows the chain to find the final IP address.

<pre>www.example.com. IN CNAME webserver.example.com.
webserver.example.com. IN A 203.0.113.50</pre>
Use cases:

* Simplifying infrastructure changes (update one A record instead of many)
* Content delivery networks (CDNs): alias your domain to the CDN's domain
* Load balancing and failover scenarios

'''MX Record (Mail Exchanger Record)'''

Specifies the mail servers responsible for receiving email for a domain. Includes a priority number (lower numbers have higher priority).

<pre>example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.</pre>
If mail1 is unavailable, the sending server tries mail2. Email delivery depends critically on properly configured MX records.

'''NS Record (Name Server Record)'''

Specifies the authoritative name servers for a domain or zone.

<pre>example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.</pre>
These records delegate authority. When you register a domain, you specify NS records pointing to your DNS provider's servers.

'''TXT Record (Text Record)'''

Stores arbitrary text data. Modern uses include:

* SPF records for email authentication: <code>"v=spf1 include:_spf.example.com ~all"</code>
* DKIM keys for email signing
* Domain verification for services (Google, Microsoft, etc.): <code>"google-site-verification=abc123xyz789"</code>
* DMARC policies for email protection

Example:

<pre>example.com. IN TXT "v=spf1 include:_spf.google.com ~all"</pre>
'''PTR Record (Pointer Record)'''

Provides reverse DNS lookup—mapping an IP address to a domain name. Used primarily for email server validation and logging.

<pre>50.113.0.203.in-addr.arpa. IN PTR mail.example.com.</pre>
Mail servers often check PTR records to verify sender legitimacy.

'''SOA Record (Start of Authority Record)'''

Defines authoritative information about a DNS zone, including the primary name server, administrator's email, serial number, and timing parameters for zone transfers and caching.

<pre>example.com. IN SOA ns1.example.com. admin.example.com. (
2024010101 ; Serial
3600 ; Refresh (1 hour)
1800 ; Retry (30 minutes)
1209600 ; Expire (2 weeks)
86400 ; Minimum TTL (1 day)
)</pre>
Time To Live (TTL)

Every DNS record includes a TTL (Time To Live) value specified in seconds. This value tells caching servers how long they can store the record before re-querying the authoritative server.

'''Short TTL (e.g., 60-300 seconds)'''

Advantages:

* Changes propagate quickly
* Useful before planned infrastructure changes
* Allows rapid failover

Disadvantages:

* Increases DNS query load
* Slightly slower for end users (more frequent resolution)
* Higher bandwidth consumption

'''Long TTL (e.g., 3600-86400 seconds)'''

Advantages:

* Reduces DNS query load significantly
* Faster for end users (more cache hits)
* Lower bandwidth consumption
* Better resilience if authoritative servers become unavailable

Disadvantages:

* Changes propagate slowly (users may see old data until TTL expires)
* Failover is slower


=== Secure Shell (SSH): Encrypted Remote Access ===

SSH (Secure Shell) is the standard protocol for secure remote access to systems. It replaced the insecure Telnet protocol in the 1990s and has become ubiquitous in system administration, DevOps, and software development.

SSH provides three critical security properties:

# '''Confidentiality''': All data (including credentials) is encrypted using symmetric encryption (AES, ChaCha20)
# '''Integrity''': Cryptographic MACs (Message Authentication Codes) prevent tampering
# '''Authentication''': Public key cryptography verifies server and optionally client identity


==== SSH Architecture ====

'''SSH is not a single protocol but a protocol suite:'''

# '''SSH-TRANS (Transport Layer Protocol, RFC 4253)''': Establishes encrypted channel, handles server authentication
# '''SSH-AUTH (Authentication Protocol, RFC 4252)''': Handles client authentication (password, public key, etc.)
# '''SSH-CONN (Connection Protocol, RFC 4254)''': Multiplexes multiple channels (terminal session, port forwarding, etc.) over one TCP connection

'''Standard Port''': TCP port 22 (well-known port)

'''Connection Establishment Sequence''':

<pre>1. TCP three-way handshake establishes connection
2. SSH version exchange (both sides advertise SSH protocol version)
3. Algorithm negotiation (agree on encryption, MAC, compression algorithms)
4. Diffie-Hellman key exchange generates session keys
5. Server authenticates itself using its host key
6. Client authenticates itself (password or public key)
7. Encrypted session established, commands can be executed</pre>

==== SSH Authentication Methods ====

SSH supports multiple authentication methods, which can be combined or used exclusively:

'''1. Password Authentication'''

The client sends the password over the encrypted SSH connection (not plaintext like Telnet). While the password is protected in transit, password authentication has weaknesses:

* Vulnerable to brute-force attacks if weak passwords are used
* Requires users to memorize or manage passwords
* Passwords can be stolen through phishing, keyloggers, or social engineering
* No way to distinguish different clients (all use the same password)

'''2. Public Key Authentication (Recommended)'''

Uses asymmetric cryptography:

* Client generates a public/private key pair
* Public key is placed on the server in <code>~/.ssh/authorized_keys</code>
* Private key remains on the client and never leaves the system
* Server challenges client to prove possession of the private key without transmitting it

'''Advantages''':

* Strong cryptographic security (typically 2048-4096 bit RSA or 256 bit Ed25519)
* No password to steal or forget
* Can use different keys for different purposes
* Keys can be protected with passphrases
* Supports automation (keys without passphrases for scripts)

'''Modern Best Practice''': Disable password authentication entirely, allowing only public key authentication.

Public Key Cryptography Review

Since public key authentication is critical to SSH security, let us review the cryptographic foundation:

'''Asymmetric Cryptography Properties''':

# Two mathematically related keys: public key and private key
# Public key can be shared openly
# Private key must be kept secret
# Data encrypted with public key can only be decrypted with private key
# Data signed with private key can be verified with public key

'''SSH Authentication Protocol''':

# Client sends username and public key to server
# Server checks if public key is in <code>~/.ssh/authorized_keys</code> for that user
# Server generates random challenge, encrypts it with client's public key, sends to client
# Client decrypts challenge with private key, computes hash, sends hash back
# Server verifies hash matches expected value
# If match: authentication succeeds (client proved possession of private key)

The private key never travels across the network. The server cannot impersonate the client because it only has the public key.


==== SSH Key Types ====

Modern SSH supports several key types with different security and performance characteristics:

'''RSA (Rivest-Shamir-Adleman)'''

* Traditional and widely supported
* Key size: 2048 or 4096 bits (3072 bits is middle ground)
* Slower than newer algorithms
* Still secure if key size is adequate (≥2048 bits)
* Command: <code>ssh-keygen -t rsa -b 4096</code>

'''Ed25519 (Edwards-curve Digital Signature Algorithm)'''

* Modern elliptic curve algorithm (introduced ~2013)
* Key size: 256 bits (much smaller than RSA)
* Faster than RSA
* Strong security properties
* Command: <code>ssh-keygen -t ed25519</code>

'''ECDSA (Elliptic Curve Digital Signature Algorithm)'''

* Older elliptic curve algorithm
* Key sizes: 256, 384, or 521 bits
* Concerns about NSA influence on NIST curves
* Ed25519 generally preferred over ECDSA for new keys
* Command: <code>ssh-keygen -t ecdsa -b 256</code>

'''Best Practice''': Use Ed25519 for new SSH keys. It offers excellent security with small key sizes and fast performance. Fall back to RSA 4096 only if connecting to older systems that don't support Ed25519.


==== SSH Host Key Verification: Trust On First Use (TOFU) ====

One of SSH's critical security features is host key verification, which protects against man-in-the-middle (MITM) attacks. This mechanism uses a "Trust On First Use" (TOFU) model.

'''The MITM Threat'''

Consider this attack scenario:

<pre>[Your Computer] ←→ [Attacker's Computer] ←→ [Real Server]</pre>
The attacker intercepts your connection, relays your commands to the real server, and relays responses back to you. From your perspective, everything appears normal, but the attacker can:

* Log all your commands and responses
* Steal credentials if you authenticate with passwords
* Modify commands before forwarding them
* Inject malicious commands

This is called a man-in-the-middle (MITM) attack.

'''SSH's Defense: Host Keys'''

Every SSH server has a unique host key (a public/private key pair) that identifies the server. The server's public host key is its cryptographic identity.

When you first connect to a server, SSH shows:

<pre>The authenticity of host 'server.example.com (203.0.113.50)' can't be established.
ED25519 key fingerprint is SHA256:abcd1234efgh5678ijkl9012mnop3456qrst7890uvwx.
Are you sure you want to continue connecting (yes/no/[fingerprint])?</pre>
This is the TOFU moment. SSH is asking: "I've never seen this server before. Do you trust this host key?"

'''If you type "yes"''':

SSH stores the server's host key in <code>~/.ssh/known_hosts</code>:

<pre>server.example.com,203.0.113.50 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
On subsequent connections, SSH verifies the server presents the same host key. If the host key changes, SSH displays an alarming warning:

<pre>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!</pre>
'''Why the Warning?'''

A changed host key indicates one of several scenarios:

# '''Legitimate''': Server was reinstalled, host key regenerated
# '''Legitimate''': Server moved to new hardware
# '''Malicious''': MITM attack in progress
# '''Configuration Error''': Connecting to wrong server

SSH conservatively assumes the worst-case scenario and refuses the connection.

'''The TOFU Model'''

"Trust On First Use" means:

* First connection: You must manually verify the host key (typically by checking a fingerprint through an out-of-band channel)
* Subsequent connections: SSH automatically verifies the host key matches the stored value

'''Comparison to PKI (Lab 8)'''

Recall from Lab 8 that TLS uses a Public Key Infrastructure (PKI) with Certificate Authorities (CAs). Let us contrast the two models:

'''PKI/CA Model (HTTPS/TLS)''':

* Server presents a certificate signed by a trusted CA
* Your browser has a list of trusted CA public keys
* Browser verifies certificate signature cryptographically
* No manual verification needed on first connection
* Scales well: one CA can sign millions of certificates

'''TOFU Model (SSH)''':

* Server presents its public host key
* No centrally trusted authority
* You must manually verify on first connection (or accept risk)
* Subsequent connections are automatically verified
* Simpler infrastructure, but first-use verification is user's responsibility

'''Why SSH Uses TOFU Instead of PKI''':

# SSH predates widespread PKI adoption
# No consensus on which CAs to trust for SSH
# PKI adds complexity and cost (certificate purchase/management)
# TOFU works well for SSH's primary use case (administrators connecting to their own servers)
# SSH certificates exist but are less common than HTTPS certificates

'''Best Practice''': On first connection, verify the host key fingerprint through a trusted channel:

* Check the fingerprint displayed in server documentation
* View the fingerprint on the server directly: <code>ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub</code>
* Compare with fingerprint shown by SSH client

For production systems, always verify host keys. For test/lab environments, the risk is lower.


==== SSH Known Hosts Format ====

The <code>~/.ssh/known_hosts</code> file stores server host keys. Format:

<pre>hostname,ip algorithm public_key</pre>
Example:

<pre>server.example.com,203.0.113.50 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
'''Hashed Format''': Some systems hash the hostname for privacy:

<pre>|1|base64hash|base64hash ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
This prevents someone with access to your known_hosts file from learning which servers you connect to.

'''Wildcard Entries''': You can use wildcards:

<pre>*.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123...</pre>
'''Management''': Remove entries when servers are legitimately reinstalled:

<syntaxhighlight lang="bash">ssh-keygen -R server.example.com</syntaxhighlight>

==== SSH Authorized Keys ====

The <code>~/.ssh/authorized_keys</code> file on the server determines which public keys can authenticate as a specific user.

'''Format''': One public key per line:

<pre>ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIdef456... user@laptop
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCghi789... user@desktop</pre>
The trailing comment (<code>user@laptop</code>) is optional but helps identify keys.

'''Permissions''': SSH is strict about file permissions for security:

<syntaxhighlight lang="bash">chmod 700 ~/.ssh # Directory: rwx------
chmod 600 ~/.ssh/authorized_keys # File: rw-------</syntaxhighlight>
If permissions are too permissive, SSH may refuse to use the keys.

'''Restricting Keys''': You can add restrictions before keys:

<pre>command="backup.sh" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIdef456... backup-key
from="203.0.113.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIghi789... admin-key</pre>
* <code>command="backup.sh"</code>: This key can only run backup.sh (useful for automation)
* <code>from="203.0.113.0/24"</code>: This key only works from specified IP range

'''SSH Agent''': For convenience, use ssh-agent to cache decrypted private keys:

<syntaxhighlight lang="bash">eval $(ssh-agent)
ssh-add ~/.ssh/id_ed25519</syntaxhighlight>
The agent holds the unlocked private key in memory, allowing multiple connections without re-entering the passphrase.


=== HyperText Transfer Protocol (HTTP): The Universal Application Protocol ===

HTTP (HyperText Transfer Protocol) was initially designed in 1991 by Tim Berners-Lee to transfer hypertext documents (HTML web pages). Over three decades, HTTP has evolved far beyond its original purpose to become the universal protocol for nearly all application-level communication on the internet.


==== Why HTTP is Everywhere ====

'''1. Simplicity'''

HTTP uses human-readable text commands:

<pre>GET /api/users HTTP/1.1
Host: api.example.com</pre>
This simplicity makes HTTP easy to:

* Debug (you can read the protocol)
* Implement (libraries exist for every language)
* Extend (add custom headers easily)

'''2. Statelessness'''

Each HTTP request is independent—the server doesn't need to maintain state between requests. This design decision has profound implications:

* Servers can handle millions of clients without per-client memory
* Horizontal scaling is trivial (add more servers, any server can handle any request)
* Failures don't cascade (if a request fails, retry without state recovery)
* Caching is straightforward (each request is independent)

State management, when needed, is handled at the application layer (cookies, sessions, tokens).

'''3. Flexible Content'''

HTTP can transfer any type of data:

* HTML documents
* JSON API responses
* XML data
* Binary files (images, videos, executables)
* Streaming data

The <code>Content-Type</code> header specifies what the body contains:

<pre>Content-Type: application/json
Content-Type: text/html
Content-Type: image/png</pre>
'''4. Firewall Friendliness'''

HTTP (port 80) and HTTPS (port 443) are almost universally allowed through firewalls. Companies may block many ports, but they cannot block web traffic without breaking internet access. Applications using HTTP/HTTPS thus avoid firewall issues that plague custom protocols.

'''5. Tooling and Infrastructure'''

Decades of investment have created rich ecosystems:

* Web servers: Apache, Nginx, Caddy, IIS
* Reverse proxies and load balancers
* CDNs (Content Delivery Networks)
* Caching proxies
* API gateways
* Monitoring and debugging tools

'''The Result''': HTTP has become the default choice for application communication. APIs that might have used custom TCP protocols now use HTTP-based REST or GraphQL. Real-time protocols that might have used custom UDP protocols now use WebSockets (which upgrade HTTP connections). Even protocols that don't naturally map to HTTP often use it anyway for operational simplicity.

HTTP Request-Response Model

HTTP uses a simple request-response pattern:

'''Client sends HTTP Request''':

<pre>METHOD PATH VERSION
Headers
(blank line)
Body (optional)</pre>
'''Server sends HTTP Response''':

<pre>VERSION STATUS_CODE STATUS_MESSAGE
Headers
(blank line)
Body (optional)</pre>
'''Example Exchange''':

Request:

<syntaxhighlight lang="http">GET /api/users/123 HTTP/1.1
Host: api.example.com
User-Agent: curl/7.68.0
Accept: application/json</syntaxhighlight>
Response:

<syntaxhighlight lang="http">HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 58

{"id":123,"name":"Alice","email":"alice@example.com"}</syntaxhighlight>

==== HTTP Methods (Verbs) ====

HTTP defines several methods that indicate the desired action:

'''GET''': Retrieve a resource

* Should not modify server state (idempotent and safe)
* Can be cached
* Examples: Load web page, fetch API data, download file

'''POST''': Submit data to create a new resource

* May modify server state
* Not idempotent (repeating creates multiple resources)
* Examples: Submit form, create new user via API

'''PUT''': Update an existing resource (or create if doesn't exist)

* Idempotent (repeating has same effect as doing once)
* Replaces entire resource
* Examples: Update user profile, upload file

'''PATCH''': Partially update a resource

* Apply partial modifications
* Not necessarily idempotent (depends on implementation)
* Examples: Update single field of a record

'''DELETE''': Remove a resource

* Idempotent (deleting twice has same effect as deleting once)
* Examples: Delete user account, remove file

'''HEAD''': Same as GET but returns only headers (no body)

* Check if resource exists
* Check content size before downloading
* Verify cache freshness

'''OPTIONS''': Query supported methods for a resource

* Used for CORS (Cross-Origin Resource Sharing) preflight requests


==== HTTP Status Codes ====

The status code indicates the result of the request. Codes are grouped:

'''1xx: Informational'''

* 100 Continue: Client should continue with request
* 101 Switching Protocols: Server switching protocols (e.g., WebSocket upgrade)

'''2xx: Success'''

* 200 OK: Request succeeded
* 201 Created: Resource created successfully
* 204 No Content: Success but no response body

'''3xx: Redirection'''

* 301 Moved Permanently: Resource moved, update bookmarks
* 302 Found: Temporary redirect
* 304 Not Modified: Cached version is still valid

'''4xx: Client Error'''

* 400 Bad Request: Malformed request
* 401 Unauthorized: Authentication required
* 403 Forbidden: Authenticated but not authorized
* 404 Not Found: Resource doesn't exist
* 429 Too Many Requests: Rate limit exceeded

'''5xx: Server Error'''

* 500 Internal Server Error: Server encountered error
* 502 Bad Gateway: Proxy received invalid response from upstream
* 503 Service Unavailable: Server temporarily overloaded or down
* 504 Gateway Timeout: Proxy timeout waiting for upstream


==== HTTP Headers ====

Headers provide metadata about the request or response. Some critical headers:

'''Request Headers''':

* <code>Host: api.example.com</code> — Required in HTTP/1.1, specifies target hostname
* <code>User-Agent: curl/7.68.0</code> — Identifies client software
* <code>Accept: application/json</code> — Content types client understands
* <code>Authorization: Bearer token123</code> — Authentication credentials
* <code>Content-Type: application/json</code> — Type of request body
* <code>Content-Length: 58</code> — Size of request body in bytes

'''Response Headers''':

* <code>Content-Type: application/json</code> — Type of response body
* <code>Content-Length: 1234</code> — Size of response body
* <code>Cache-Control: max-age=3600</code> — Caching directives
* <code>Set-Cookie: session=abc123; HttpOnly</code> — Set cookie in browser
* <code>Location: /api/users/456</code> — Redirect target (with 3xx status)
* <code>Server: nginx/1.18.0</code> — Server software (often hidden for security)

'''Security Headers''' (modern best practices):

* <code>Strict-Transport-Security: max-age=31536000</code> — Force HTTPS
* <code>Content-Security-Policy: default-src 'self'</code> — Mitigate XSS attacks
* <code>X-Frame-Options: DENY</code> — Prevent clickjacking


==== Virtual Hosting: Multiple Sites on One IP ====

HTTP's <code>Host</code> header enables virtual hosting—running multiple websites on a single IP address. The web server examines the <code>Host</code> header to determine which site the request targets:

<syntaxhighlight lang="http">GET / HTTP/1.1
Host: site1.example.com</syntaxhighlight>
vs.

<syntaxhighlight lang="http">GET / HTTP/1.1
Host: site2.example.com</syntaxhighlight>
Both requests go to the same IP address (e.g., 203.0.113.50) and same port (80 or 443), but the <code>Host</code> header tells the server which site to serve. This is how shared hosting providers can host thousands of websites on relatively few servers.

'''HTTPS Complication''': Virtual hosting works seamlessly for HTTP, but HTTPS initially had issues because the TLS handshake occurs before the HTTP request (so the server doesn't know which certificate to present). Server Name Indication (SNI), added to TLS in 2003, solved this by including the hostname in the TLS handshake.


==== HTTP/1.1 vs. HTTP/2 vs. HTTP/3 ====

'''HTTP/1.1''' (1997, RFC 2616, updated RFC 7230-7235):

* Text-based protocol
* One request per connection (or serial requests with keep-alive)
* Head-of-line blocking (one slow request delays all subsequent requests)
* Still widely used

'''HTTP/2''' (2015, RFC 7540):

* Binary protocol (more efficient parsing)
* Multiplexing (multiple concurrent requests on one connection)
* Server push (server can send resources before client requests them)
* Header compression (reduces overhead)
* Requires HTTPS in practice (browsers only support HTTP/2 over TLS)
* Growing adoption

'''HTTP/3''' (2022, RFC 9114):

* Uses QUIC instead of TCP (UDP-based transport with built-in TLS)
* Reduces connection establishment latency
* Better handling of packet loss
* Connection migration (survive IP address changes)
* Newest, increasing adoption

For this lab, we use HTTP/1.1 for simplicity, but modern production systems increasingly deploy HTTP/2 and HTTP/3.

Reverse Proxies: The Modern Web Architecture Pattern

A reverse proxy is a server that sits in front of backend servers and forwards client requests to them. The client believes it is talking directly to the origin server, unaware of the proxy's existence.

'''Terminology Clarification''':

* '''Forward Proxy''': Client knows about proxy, uses it to access external servers (e.g., corporate proxy for internet access)
* '''Reverse Proxy''': Client unaware of proxy, thinks it's talking to the origin server directly

Reverse Proxy Benefits

'''1. Load Balancing'''

Distribute requests across multiple backend servers:

<pre>Client → Reverse Proxy → [Backend 1]
→ [Backend 2]
→ [Backend 3]</pre>
Strategies:

* Round-robin: Cycle through backends in order
* Least connections: Send to backend with fewest active connections
* IP hash: Always send same client to same backend (session affinity)

'''2. TLS Termination'''

The reverse proxy handles TLS encryption/decryption:

<pre>Client ←(HTTPS)→ Reverse Proxy ←(HTTP)→ Backend Servers</pre>
Benefits:

* Backend servers don't need TLS configuration or certificates
* Centralized certificate management
* Reduces computational load on backends (TLS crypto is expensive)
* Simplifies backend server configuration

'''3. Caching'''

Cache responses to reduce backend load:

<pre>Client → Reverse Proxy (check cache) → Backend (if cache miss)</pre>
Subsequent requests for the same resource are served from cache without hitting backends. Can dramatically improve performance and reduce costs.

'''4. Compression'''

The proxy can compress responses (gzip, brotli) before sending to clients, reducing bandwidth:

<pre>Backend → Proxy (compress) → Client</pre>
'''5. Security'''

* Hide backend server details (IP addresses, software versions)
* Web Application Firewall (WAF) functionality
* Rate limiting and DDoS protection
* Centralized logging and monitoring

'''6. Path-Based Routing''' (Critical for Microservices)

Route requests to different backends based on URL path:

<pre>client request /api/users → Reverse Proxy → User Service
client request /api/orders → Reverse Proxy → Order Service
client request /api/products → Reverse Proxy → Product Service</pre>
From the client's perspective, everything is at one domain (e.g., <code>api.example.com</code>). The reverse proxy routes to appropriate microservices based on path. This is the architectural pattern that enables modern microservices.


==== Path-Based Routing in Depth ====

Path-based routing is the killer feature that made HTTP the universal protocol. Let us examine why:

'''The Problem Without Path-Based Routing''':

Suppose you have three backend services:

* User service (manages user accounts)
* Order service (manages orders)
* Product service (manages product catalog)

Without path-based routing, clients must know the specific addresses of each service:

<pre>user-service.example.com/users
order-service.example.com/orders
product-service.example.com/products</pre>
'''Problems''':

# Clients must maintain knowledge of all services
# Adding/removing/renaming services breaks clients
# Difficult to manage CORS (Cross-Origin Resource Sharing) with multiple domains
# More complex DNS management
# More complex TLS certificate management (separate cert for each service)

'''The Solution With Path-Based Routing''':

One unified API endpoint:

<pre>api.example.com/users → routes to User Service
api.example.com/orders → routes to Order Service
api.example.com/products → routes to Product Service</pre>
Reverse proxy configuration:

<pre>if path starts with /users → forward to user-service:3001
if path starts with /orders → forward to order-service:3002
if path starts with /products → forward to product-service:3003</pre>
'''Benefits''':

# Clients see one consistent API domain
# Backend services can change without client awareness
# One TLS certificate for all services
# Simplified CORS configuration
# Centralized authentication and rate limiting

'''This is How Modern Systems Work''':

* '''Kubernetes''': Ingress controllers route paths to services
* '''AWS''': Application Load Balancers route paths to target groups
* '''Microservices''': API Gateway routes paths to microservices
* '''Netflix, Uber, Airbnb''': All use path-based routing at scale

You will implement this pattern in the exercises.

Evolution from Monoliths to Microservices

Understanding path-based routing requires understanding the architectural evolution:

'''Monolithic Architecture''' (Traditional):

<pre>Single Application
├── User Management
├── Order Processing
├── Product Catalog
├── Payment Processing
└── Notification System</pre>
All functionality in one codebase, runs as one process. Advantages: simple deployment, shared database, no network calls between components. Disadvantages: hard to scale specific components, one bug can crash entire system, difficult to update independently.

'''Microservices Architecture''' (Modern):

<pre>User Service ──┐
Order Service ──┤
Product Service ──├── Reverse Proxy ── Clients
Payment Service ──┤
Notification Svc ──┘</pre>
Each service is independent: separate codebase, separate process, separate deployment, separate scaling. Advantages: scale components independently, update services without affecting others, use different technologies per service, isolated failures. Disadvantages: increased operational complexity, network latency between services, distributed system challenges.

'''The Reverse Proxy's Role''': Makes microservices look like a monolith to clients. Clients don't know or care that backend is distributed—they just make requests to one API endpoint.

Observability and Debugging

Modern reverse proxies provide rich observability:

'''Access Logs''': Record every request:

<pre>203.0.113.42 - - [05/Dec/2024:14:23:45 +0000] "GET /api/users HTTP/1.1" 200 1234 "-" "curl/7.68.0"</pre>
Fields: client IP, timestamp, method, path, protocol version, status code, response size, referer, user-agent

'''Error Logs''': Record issues:

<pre>[error] 2024/12/05 14:23:50 upstream timed out (110: Connection timed out) while connecting to upstream</pre>
'''Metrics''': Request rate, error rate, latency percentiles (p50, p95, p99), upstream health

'''Distributed Tracing''': Track requests across services using trace IDs in headers:

<pre>X-Request-ID: 7f2a3b4c-8d9e-4f1a-b2c3-d4e5f6a7b8c9</pre>
When troubleshooting issues, these logs and metrics are invaluable.


== Laboratory Exercises ==


=== Exercise A: DNS Resolution and Analysis ===

Objective: Use DNS client tools to query various record types and observe the DNS resolution process. Understand the difference between authoritative and recursive queries, analyze TTL values, and measure resolution performance.

Required Topology: You must have the Red and Blue namespaces from Lab 8 with IP addresses 10.0.0.1 and 10.0.0.2 respectively, connected via bridge br0. Verify connectivity before proceeding:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.2</syntaxhighlight>
If this fails, recreate your Lab 8 topology before continuing.


==== Basic DNS Queries with dig ====

The <code>dig</code> (Domain Information Groper) tool is the primary DNS debugging utility. It provides detailed information about DNS queries and responses.

'''Step 1''': Verify dig is installed:

<syntaxhighlight lang="bash">dig -v</syntaxhighlight>
'''Expected output''':

<pre>DiG 9.18.1-1ubuntu1.3-Ubuntu</pre>
If not installed: <code>sudo apt install dnsutils</code>

'''Step 2''': Perform a basic A record query for google.com:

<syntaxhighlight lang="bash">dig google.com</syntaxhighlight>
'''Expected output''' (abbreviated):

<pre>; <<>> DiG 9.18.1-1ubuntu1.3-Ubuntu <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 163 IN A 142.250.185.46

;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri Dec 05 14:30:22 UTC 2024
;; MSG SIZE rcvd: 55</pre>
'''Analysis''':

Let us dissect this output:

'''Header Section''':

* <code>status: NOERROR</code> — Query succeeded
* <code>id: 12345</code> — Random query ID for matching requests/responses
* <code>flags: qr rd ra</code> —
** <code>qr</code>: Query Response (this is a response, not a query)
** <code>rd</code>: Recursion Desired (client requested recursive resolution)
** <code>ra</code>: Recursion Available (server supports recursive queries)

'''Question Section''':

<pre>;google.com. IN A</pre>
This shows what we asked for:

* <code>google.com.</code> — Domain name (with trailing dot, the FQDN)
* <code>IN</code> — Internet class (as opposed to other historical DNS classes)
* <code>A</code> — Record type (IPv4 address)

'''Answer Section''':

<pre>google.com. 163 IN A 142.250.185.46</pre>
This is the answer:

* <code>google.com.</code> — Domain queried
* <code>163</code> — TTL (Time To Live) in seconds, countdown starts when received
* <code>IN</code> — Internet class
* <code>A</code> — Record type
* <code>142.250.185.46</code> — The IPv4 address

'''Metadata''':

* <code>Query time: 23 msec</code> — Time to get response (includes network latency and resolution time)
* <code>SERVER: 127.0.0.53#53</code> — DNS server queried (systemd-resolved on Ubuntu)
* <code>MSG SIZE rcvd: 55</code> — Response packet size in bytes

'''Step 3''': Query a specific DNS server directly (bypass systemd-resolved):

<syntaxhighlight lang="bash">dig @8.8.8.8 google.com</syntaxhighlight>
The <code>@8.8.8.8</code> specifies Google Public DNS. Compare the query time to the previous result.

'''Step 4''': Query an IPv6 address (AAAA record):

<syntaxhighlight lang="bash">dig google.com AAAA</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 299 IN AAAA 2607:f8b0:4004:c07::66</pre>
Note: You might see multiple AAAA records if Google has multiple IPv6 addresses for redundancy.

'''Step 5''': Query mail server records (MX records):

<syntaxhighlight lang="bash">dig google.com MX</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 3599 IN MX 10 smtp.google.com.</pre>
The number (10) is the priority. Lower numbers have higher priority. If multiple MX records exist, mail servers try the lowest priority number first.

'''Step 6''': Query name server records (NS records):

<syntaxhighlight lang="bash">dig google.com NS</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 21599 IN NS ns1.google.com.
google.com. 21599 IN NS ns2.google.com.
google.com. 21599 IN NS ns3.google.com.
google.com. 21599 IN NS ns4.google.com.</pre>
These are Google's authoritative name servers. These servers have definitive authority over google.com records.

'''Step 7''': Query text records (TXT records):

<syntaxhighlight lang="bash">dig google.com TXT</syntaxhighlight>
'''Expected output''' (answer section):

<pre>;; ANSWER SECTION:
google.com. 3599 IN TXT "v=spf1 include:_spf.google.com ~all"
google.com. 3599 IN TXT "facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com. 3599 IN TXT "google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"</pre>
TXT records store arbitrary text. Common uses: SPF records for email authentication, domain verification for services, DKIM public keys.

'''Step 8''': Request short output format:

<syntaxhighlight lang="bash">dig +short google.com</syntaxhighlight>
'''Expected output''':

<pre>142.250.185.46</pre>
Just the IP address, no verbose information. Useful for scripts.

'''Step 9''': Trace the DNS resolution path:

<syntaxhighlight lang="bash">dig +trace google.com</syntaxhighlight>
'''Expected output''' (abbreviated):

<pre>. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
[... other root servers ...]

;; Received 239 bytes from 8.8.8.8#53 in 23 ms

com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
[... other .com TLD servers ...]

;; Received 1173 bytes from 192.5.5.241#53(a.root-servers.net) in 87 ms

google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
[... other google.com name servers ...]

;; Received 836 bytes from 192.12.94.30#53(e.gtld-servers.net) in 103 ms

google.com. 300 IN A 142.250.185.46

;; Received 55 bytes from 216.239.32.10#53(ns1.google.com) in 11 ms</pre>
This shows the complete resolution process:

# Query root servers → get .com TLD servers
# Query .com TLD servers → get google.com authoritative servers
# Query google.com authoritative servers → get final answer


=== Deliverable A ===

Submit screenshots showing:

# Output of <code>dig</code> commands for A, AAAA, MX, NS, and TXT records for two different domains (suggestion: use a domain like station01.internal.arh.pub.ro, or stud.etti.pub.ro for MX)
# Output of <code>dig +trace</code> for any domain
# Output of two consecutive <code>dig</code> queries showing TTL countdown


=== Exercise B: SSH Configuration and Key-Based Authentication ===

Objective: Configure SSH server and client, generate Ed25519 key pairs, implement key-based authentication, understand the Trust On First Use (TOFU) security model, and observe host key verification


==== Part 1: Verifying SSH Installation ====

'''Step 1''': Check if SSH server is installed:

<syntaxhighlight lang="bash">dpkg -l | grep openssh-server</syntaxhighlight>
'''Expected output''':

<pre>ii openssh-server 1:8.9p1-3ubuntu0.4 amd64 secure shell (SSH) server</pre>
If not installed:

<syntaxhighlight lang="bash">sudo apt install openssh-server openssh-client</syntaxhighlight>
'''Step 2''': Check SSH service status:

<syntaxhighlight lang="bash">sudo systemctl status sshd</syntaxhighlight>
If not running:

<syntaxhighlight lang="bash">sudo systemctl start sshd
sudo systemctl enable sshd</syntaxhighlight>

==== Part 2: Generating SSH Key Pairs ====

We'll generate Ed25519 keys because they offer strong security with small key sizes and fast performance.

'''Step 1''': Generate a key pair as your current user:

<syntaxhighlight lang="bash">ssh-keygen -t ed25519 -C "lab-key"</syntaxhighlight>
'''Expected interaction''':

<pre>Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519): [press Enter]
Enter passphrase (empty for no passphrase): [press Enter for no passphrase]
Enter same passphrase again: [press Enter]
Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:xyz789abc123def456ghi789jkl012mno345pqr678 lab-key</pre>
'''Key Decisions''':

* '''File location''': Accept default (<code>~/.ssh/id_ed25519</code>)
* '''Passphrase''': For this lab, skip the passphrase for simplicity. In production, always use a strong passphrase to protect the private key. A passphrase encrypts the private key file—even if an attacker steals the file, they cannot use it without the passphrase.

'''Step 2''': Examine the generated keys:

<syntaxhighlight lang="bash">ls -la ~/.ssh/</syntaxhighlight>
'''Expected output''':

<pre>total 16
drwx------ 2 youruser youruser 4096 Dec 5 14:30 .
drwxr-x--- 8 youruser youruser 4096 Dec 5 14:30 ..
-rw------- 1 youruser youruser 411 Dec 5 14:30 id_ed25519
-rw-r--r-- 1 youruser youruser 99 Dec 5 14:30 id_ed25519.pub</pre>
'''Critical''': Private key (<code>id_ed25519</code>) has mode 600 (readable/writable only by owner). Public key (<code>.pub</code>) has mode 644 (world-readable).

'''Step 3''': View your public key:

<syntaxhighlight lang="bash">cat ~/.ssh/id_ed25519.pub</syntaxhighlight>
This public key can be freely shared. You'll copy this to accounts you want to access.


==== Part 3: Setting Up Key-Based Authentication ====

Configure SSH so you can connect to the <code>sshtest</code> account using your key.

'''Step 1''': Copy your public key to the test user's authorized_keys:

<syntaxhighlight lang="bash">cat ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keys
sudo chmod 600 /home/.ssh/authorized_keys</syntaxhighlight>
'''Step 2''': Verify the setup:

<syntaxhighlight lang="bash">sudo ls -la /home/sshtest/.ssh/
sudo cat ~/.ssh/authorized_keys</syntaxhighlight>
'''Critical Permissions''':

* <code>~/.ssh/</code>: 700 (drwx------)
* <code>authorized_keys</code>: 600 (-rw-------)
* Owner must be the target user

If permissions are wrong, SSH will silently ignore the keys and fall back to password authentication.


==== Part 4: First Connection - Trust On First Use (TOFU) ====

'''Step 1''': Connect to localhost as the test user:

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
'''Expected output (first connection)''':

<pre>The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:abcd1234efgh5678ijkl9012mnop3456qrst7890uvwx.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?</pre>
'''This is the TOFU (Trust On First Use) moment.'''

SSH is asking you to verify the server's identity. In production, you would:

# Check the server's host key fingerprint: <code>ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub</code>
# Compare the fingerprint displayed by SSH with the server's actual fingerprint
# If they match, type <code>yes</code>. If they don't match, '''do not proceed''' (possible MITM attack)

For this lab, type <code>yes</code>:

<pre>Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
sshtest@hostname:~$</pre>
'''You are now connected!''' The connection succeeded using key-based authentication (no password prompt).

'''Step 2''': Explore the connection:

<syntaxhighlight lang="bash">whoami
pwd
hostname</syntaxhighlight>
'''Step 3''': Exit the SSH session:

<syntaxhighlight lang="bash">exit</syntaxhighlight>

==== Part 5: Understanding known_hosts ====

'''Step 1''': Examine the known_hosts file:

<syntaxhighlight lang="bash">cat ~/.ssh/known_hosts</syntaxhighlight>
'''Expected output''':

<pre>localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAbc123def456ghi789jkl012mno345pqr678stu901vwx</pre>
This file stores trusted host keys. Format: <code>hostname/ip algorithm public_key</code>

On subsequent connections, SSH verifies the server presents the same host key. If the key changes, SSH displays a warning.

'''Step 2''': Connect again:

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
'''Expected behavior''': No host key prompt this time—immediate connection. SSH verified the host key matches the one in known_hosts.

'''Step 3''': Exit:

<syntaxhighlight lang="bash">exit</syntaxhighlight>

==== Part 6: Simulating a Host Key Change ====

We'll deliberately change the server's host key to see SSH's security warning.

'''Step 1''': Regenerate the host key:

<syntaxhighlight lang="bash">sudo rm /etc/ssh/ssh_host_ed25519_key*
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo systemctl restart sshd</syntaxhighlight>
'''Step 2''': Attempt to connect:

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
'''Expected output''':

<pre>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:new_fingerprint_here.
Please contact your system administrator.
Add correct host key in /home/youruser/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/youruser/.ssh/known_hosts:1
remove with:
ssh-keygen -f "/home/youruser/.ssh/known_hosts" -R "localhost"
Host key for localhost has changed and you have requested strict checking.
Host key verification failed.</pre>
'''SSH refuses to connect!''' This is the security mechanism in action. SSH detected that the server's host key changed, which could indicate:

# Legitimate server reinstallation
# Man-in-the-middle attack

SSH conservatively assumes the worst case and blocks the connection.

'''Step 3''': Remove the old host key:

<syntaxhighlight lang="bash">ssh-keygen -f ~/.ssh/known_hosts -R "localhost"</syntaxhighlight>
'''Expected output''':

<pre># Host localhost found: line 1
/home/youruser/.ssh/known_hosts updated.
Original contents retained as /home/youruser/.ssh/known_hosts.old</pre>
'''Step 4''': Reconnect (you'll see the TOFU prompt again):

<syntaxhighlight lang="bash">ssh $USER@localhost</syntaxhighlight>
Type <code>yes</code> to trust the new host key.


=== Deliverable B ===

Submit screenshots showing:

# The TOFU prompt on first SSH connection
# Contents of <code>~/.ssh/id_ed25519.pub</code>
# Contents of <code>~/.ssh/authorized_keys</code>
# Contents of <code>~/.ssh/known_hosts</code>
# The "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" message
# Successful SSH connection after resolving the host key change


=== Exercise C: HTTP Services and Reverse Proxy ===

'''Objective''': Build simple HTTP backend services in network namespaces and configure Caddy as a reverse proxy with path-based routing.


==== Part 1: Installing Caddy ====

'''Step 1''': Install Caddy:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y caddy curl</syntaxhighlight>
'''Step 2''': Verify installation:

<syntaxhighlight lang="bash">caddy version</syntaxhighlight>
Expected output: <code>v2.6.2</code> or similar


==== Part 2: Creating Simple Backend Services ====

We'll create basic file-serving HTTP servers in the Red and Blue namespaces.

'''Step 1''': Create content directories and files for Red service:

<syntaxhighlight lang="bash"># Create directory for Red service
mkdir -p ~/red-service
cd ~/red-service

# Create an index file
cat > index.html << 'EOF'
<!DOCTYPE html>
<html>
<head><title>Red Service</title></head>
<body>
<h1>Red Service</h1>
Hello from Red namespace!
IP: 10.0.0.1 | Port: 8001
</body>
</html>
EOF

# Create an API response file
mkdir -p api
cat > api/data.json << 'EOF'
{
"service": "Red Service",
"namespace": "red",
"ip": "10.0.0.1",
"status": "running"
}
EOF</syntaxhighlight>
'''Step 2''': Start Red service in its namespace:

<syntaxhighlight lang="bash"># Start HTTP server in Red namespace (run in background with &)
sudo ip netns exec red python3 -m http.server 8001 --bind 10.0.0.1 --directory ~/red-service &</syntaxhighlight>
Expected output: <code>Serving HTTP on 10.0.0.1 port 8001 (http://10.0.0.1:8001/) ...</code>

'''Step 3''': Create content for Blue service:

<syntaxhighlight lang="bash"># Create directory for Blue service
mkdir -p ~/blue-service
cd ~/blue-service

# Create an index file
cat > index.html << 'EOF'
<!DOCTYPE html>
<html>
<head><title>Blue Service</title></head>
<body>
<h1>Blue Service</h1>
Hello from Blue namespace!
IP: 10.0.0.2 | Port: 8002
</body>
</html>
EOF

# Create an API response file
mkdir -p api
cat > api/data.json << 'EOF'
{
"service": "Blue Service",
"namespace": "blue",
"ip": "10.0.0.2",
"status": "running"
}
EOF</syntaxhighlight>
'''Step 4''': Start Blue service in its namespace:

<syntaxhighlight lang="bash"># Start HTTP server in Blue namespace
sudo ip netns exec blue python3 -m http.server 8002 --bind 10.0.0.2 --directory ~/blue-service &</syntaxhighlight>
'''Step 5''': Test the backend services directly:

<syntaxhighlight lang="bash"># Test Red service
curl http://10.0.0.1:8001/

# Test Blue service
curl http://10.0.0.2:8002/

# Test JSON endpoints
curl http://10.0.0.1:8001/api/data.json
curl http://10.0.0.2:8002/api/data.json</syntaxhighlight>
You should see the HTML and JSON content from each service.


==== Part 3: Configuring Caddy Reverse Proxy ====

'''Step 1''': Create a Caddyfile:

<syntaxhighlight lang="bash">cd ~
cat > Caddyfile << 'EOF'
# Caddy Reverse Proxy Configuration

:8080 {
# Health check endpoint
handle /health {
respond "OK - API Gateway Running" 200
}

# Root path
handle / {
respond "API Gateway - Use /red/ or /blue/ paths" 200
}

# Route /red/* to Red service (strips /red prefix)
handle_path /red/* {
reverse_proxy 10.0.0.1:8001
}

# Route /blue/* to Blue service (strips /blue prefix)
handle_path /blue/* {
reverse_proxy 10.0.0.2:8002
}

# Enable logging
log {
output stdout
format console
}
}
EOF</syntaxhighlight>
'''Understanding the Configuration''':

* <code>:8080</code> - Listen on port 8080
* <code>handle /health</code> - Health check endpoint (doesn't go to backends)
* <code>handle_path /red/*</code> - Strips <code>/red</code> prefix before forwarding
** Client requests <code>/red/api/data.json</code> → Backend receives <code>/api/data.json</code>
* <code>reverse_proxy 10.0.0.1:8001</code> - Forward to Red service
* Similar logic for Blue service

'''Step 2''': Start Caddy:

<syntaxhighlight lang="bash">caddy run --config ~/Caddyfile</syntaxhighlight>
Expected output:

<pre>INFO using config from file
INFO serving initial configuration</pre>
Leave this terminal open to see request logs.


==== Part 4: Testing Path-Based Routing ====

Open a '''new terminal''' for testing.

'''Step 1''': Test the root path:

<syntaxhighlight lang="bash">curl http://localhost:8080/</syntaxhighlight>
Expected output: <code>API Gateway - Use /red/ or /blue/ paths</code>

'''Step 2''': Test health check:

<syntaxhighlight lang="bash">curl http://localhost:8080/health</syntaxhighlight>
Expected output: <code>OK - API Gateway Running</code>

'''Step 3''': Test Red service through proxy:

<syntaxhighlight lang="bash">curl http://localhost:8080/red/</syntaxhighlight>
You should see the Red service HTML page.

<syntaxhighlight lang="bash">curl http://localhost:8080/red/api/data.json</syntaxhighlight>
Expected output:

<syntaxhighlight lang="json">{
"service": "Red Service",
"namespace": "red",
"ip": "10.0.0.1",
"status": "running"
}</syntaxhighlight>
'''Step 4''': Test Blue service through proxy:

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/</syntaxhighlight>
You should see the Blue service HTML page.

<syntaxhighlight lang="bash">curl http://localhost:8080/blue/api/data.json</syntaxhighlight>
Expected output:

<syntaxhighlight lang="json">{
"service": "Blue Service",
"namespace": "blue",
"ip": "10.0.0.2",
"status": "running"
}</syntaxhighlight>
'''Step 5''': Test with verbose output to see headers:

<syntaxhighlight lang="bash">curl -v http://localhost:8080/red/api/data.json</syntaxhighlight>
Expected output (key parts):

<pre>> GET /red/api/data.json HTTP/1.1
> Host: localhost:8080
...
< HTTP/1.1 200 OK
< Content-Type: application/json
< Server: Caddy
...
{JSON response}</pre>
'''Observation''':

* Client requested <code>/red/api/data.json</code>
* Caddy stripped <code>/red</code> and forwarded <code>/api/data.json</code> to backend
* Response comes back through Caddy (notice <code>Server: Caddy</code> header)


==== Part 5: Understanding the Flow ====

'''Request Flow Diagram''':

<pre>Client Request: http://localhost:8080/red/api/data.json
|
v
Caddy (port 8080)
|
| Strips /red prefix
| Path becomes: /api/data.json
v
Red Service (10.0.0.1:8001)
|
| Serves file: ~/red-service/api/data.json
v
Response back through Caddy
|
v
Client receives JSON</pre>

==== Part 6: Cleanup ====

When finished testing:

<syntaxhighlight lang="bash"># Stop Caddy (Ctrl+C in Caddy terminal)

# Kill Python servers
pkill -f "python3 -m http.server 8001"
pkill -f "python3 -m http.server 8002"

# Or kill all Python HTTP servers
sudo pkill -f "http.server"</syntaxhighlight>

=== Deliverable C ===

Submit screenshots showing:

# Output of <code>curl http://localhost:8080/</code> (root path)
# Output of <code>curl http://localhost:8080/health</code>
# Output of <code>curl http://localhost:8080/red/api/data.json</code>
# Output of <code>curl http://localhost:8080/blue/api/data.json</code>
# Output of <code>curl -v http://localhost:8080/red/</code> showing response headers
# Your complete Caddyfile contents


== Common Troubleshooting ==

This section covers common issues you may encounter during the lab exercises.


=== DNS Issues ===

'''Problem''': DNS queries fail or time out

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check DNS resolver configuration
cat /etc/resolv.conf

# Test with different DNS servers
dig @8.8.8.8 google.com
dig @1.1.1.1 google.com</syntaxhighlight>
'''Solutions''':

* Verify network connectivity: <code>ping 8.8.8.8</code>
* Check firewall rules: <code>sudo iptables -L -n | grep 53</code>
* Try alternative DNS servers

'''Problem''': "connection timed out; no servers could be reached"

'''Cause''': No DNS resolver configured or resolver unreachable

'''Solution''':

<syntaxhighlight lang="bash"># Add Google DNS to resolv.conf
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf</syntaxhighlight>

=== SSH Issues ===

'''Problem''': "Permission denied (publickey)"

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check SSH with verbose output
ssh -v testuser@10.0.0.2

# Verify key permissions
ls -la ~/.ssh/id_ed25519

# Check authorized_keys on server
sudo ls -la /home/testuser/.ssh/authorized_keys</syntaxhighlight>
'''Common Causes''':

# Wrong permissions on private key (must be 600)
# Wrong permissions on authorized_keys (must be 600)
# Wrong ownership of .ssh directory
# Public key not in authorized_keys
# Private key not loaded

'''Solutions''':

<syntaxhighlight lang="bash"># Fix permissions
chmod 600 ~/.ssh/id_ed25519
chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

# Verify key is loaded
ssh-add -l

# Add key if not loaded
ssh-add ~/.ssh/id_ed25519</syntaxhighlight>
'''Problem''': "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!"

'''Cause''': Server's host key changed (legitimate reinstall or potential MITM attack)

'''Solution''' (if change is legitimate):

<syntaxhighlight lang="bash"># Remove old host key
ssh-keygen -R 10.0.0.2

# Reconnect and verify new fingerprint
ssh testuser@10.0.0.2</syntaxhighlight>
'''Problem''': SSH connection hangs

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check if SSH server is running
sudo ss -tlnp | grep :22

# Test connectivity
nc -zv 10.0.0.2 22</syntaxhighlight>
'''Solutions''':

* Restart SSH server: <code>sudo systemctl restart sshd</code>
* Check firewall rules
* Verify network namespace connectivity


=== HTTP/Caddy Issues ===

'''Problem''': Caddy fails to start

'''Diagnostics''':

<syntaxhighlight lang="bash"># Validate configuration
caddy validate --config /etc/caddy/Caddyfile

# Check if port is already in use
sudo ss -tlnp | grep :8080

# View Caddy logs
sudo journalctl -u caddy -n 50</syntaxhighlight>
'''Common Causes''':

# Port already in use
# Syntax error in Caddyfile
# Permission issues

'''Solutions''':

<syntaxhighlight lang="bash"># Kill process using port 8080
sudo fuser -k 8080/tcp

# Fix Caddyfile syntax
caddy fmt --overwrite /etc/caddy/Caddyfile

# Run Caddy with elevated privileges if needed
sudo caddy run --config /etc/caddy/Caddyfile</syntaxhighlight>
'''Problem''': Reverse proxy returns "502 Bad Gateway"

'''Cause''': Backend service not running or unreachable

'''Diagnostics''':

<syntaxhighlight lang="bash"># Test backend directly
curl http://10.0.0.1:8001
curl http://10.0.0.2:8002

# Check if backend processes are running
sudo ip netns exec red ps aux | grep python
sudo ip netns exec blue ps aux | grep python

# Check connectivity from host to namespace
ping -c 2 10.0.0.1
ping -c 2 10.0.0.2</syntaxhighlight>
'''Solutions''':

* Restart backend services
* Verify namespace network configuration
* Check backend logs for errors

'''Problem''': Path routing not working correctly

'''Diagnostics''':

<syntaxhighlight lang="bash"># Test with verbose curl
curl -v http://localhost:8080/red/

# Check Caddy access logs
sudo tail -f /var/log/caddy/access.log</syntaxhighlight>
'''Solution''': Verify Caddyfile syntax, especially <code>handle_path</code> directives. Ensure path prefixes match exactly.


=== Network Namespace Issues ===

'''Problem''': Cannot ping between namespaces

'''Diagnostics''':

<syntaxhighlight lang="bash"># Check interface status
sudo ip netns exec red ip link show
sudo ip netns exec blue ip link show

# Check IP addresses
sudo ip netns exec red ip addr show
sudo ip netns exec blue ip addr show

# Check routing
sudo ip netns exec red ip route show</syntaxhighlight>
'''Solutions''':

* Recreate namespace configuration from Lab 8
* Verify veth pairs are connected
* Check bridge configuration

'''Problem''': Services in namespace cannot access internet

'''Cause''': No default gateway or NAT configured

'''Solution''': Configure NAT on host (if needed for external access):

<syntaxhighlight lang="bash"># Enable IP forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# Add NAT rule
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE</syntaxhighlight>

== Additional Protocol Information ==

This appendix provides information about other application protocols you may encounter.


=== Email Protocols ===

'''SMTP (Simple Mail Transfer Protocol)'''

* Port: 25 (unencrypted), 587 (submission with STARTTLS), 465 (SMTPS)
* Purpose: Sending email between servers
* Client-to-server: Port 587
* Server-to-server: Port 25
* Note: Port 25 often blocked by ISPs to prevent spam

'''IMAP (Internet Message Access Protocol)'''

* Port: 143 (unencrypted), 993 (IMAPS)
* Purpose: Reading email with server synchronization
* Advantages: Emails stay on server, accessible from multiple devices
* Modern replacement for POP3

'''POP3 (Post Office Protocol v3)'''

* Port: 110 (unencrypted), 995 (POP3S)
* Purpose: Downloading email to client
* Downloads emails and typically deletes from server
* Legacy protocol, IMAP preferred today


=== Database Protocols ===

'''MySQL'''

* Port: 3306
* Protocol: MySQL wire protocol (proprietary)
* Common tools: mysql client, MySQL Workbench

'''PostgreSQL'''

* Port: 5432
* Protocol: PostgreSQL wire protocol
* Common tools: psql client, pgAdmin

'''MongoDB'''

* Port: 27017
* Protocol: MongoDB wire protocol
* NoSQL document database

'''Redis'''

* Port: 6379
* Protocol: RESP (Redis Serialization Protocol)
* In-memory data structure store


=== Other Common Protocols ===

'''FTP (File Transfer Protocol)'''

* Port: 21 (control), 20 (data)
* Legacy file transfer protocol
* Security issues: Transmits credentials in cleartext
* Modern alternatives: SFTP (SSH File Transfer Protocol), FTPS (FTP over SSL/TLS)

'''LDAP (Lightweight Directory Access Protocol)'''

* Port: 389 (unencrypted), 636 (LDAPS)
* Purpose: Directory services (user authentication, organizational data)
* Common in enterprises for centralized authentication

'''RDP (Remote Desktop Protocol)'''

* Port: 3389
* Purpose: Remote desktop access (Windows)
* Proprietary Microsoft protocol

'''VNC (Virtual Network Computing)'''

* Port: 5900+ (5900, 5901, etc.)
* Purpose: Remote desktop access (cross-platform)
* Open protocol, multiple implementations

'''NTP (Network Time Protocol)'''

* Port: 123
* Purpose: Clock synchronization
* Critical for distributed systems, logging, security

'''Syslog'''

* Port: 514 (UDP/TCP)
* Purpose: Logging infrastructure
* Centralized log collection


=== Ports to Avoid ===

'''Insecure Legacy Protocols''' (never use in production):

* Port 21: FTP (use SFTP or FTPS instead)
* Port 23: Telnet (use SSH instead)
* Port 69: TFTP (use SFTP or SCP instead)
* Port 110: POP3 unencrypted (use POP3S or IMAP)
* Port 143: IMAP unencrypted (use IMAPS)
* Port 389: LDAP unencrypted (use LDAPS)
* Port 445: SMB (often exploited, use VPN if needed)
* Port 512-514: rlogin, rsh, rexec (use SSH instead)

These protocols transmit data (including credentials) in cleartext and/or have known security vulnerabilities.


== Deliverables and Assessment ==

Submit a single PDF document containing all required elements. Organize clearly with section headers matching exercise labels.


== Additional Resources ==

This lab introduced the dominant application layer protocols that form the foundation of modern internet services. You now understand how DNS enables service discovery, SSH provides secure remote access, and HTTP(S) serves as the universal protocol for APIs and web services.


=== For Further Study ===

'''DNS Deep Dives''':

* Setting up authoritative DNS with BIND9 or PowerDNS
* DNS security: DNSSEC for cryptographic verification of DNS responses
* DNS over HTTPS (DoH) and DNS over TLS (DoT) for encrypted DNS queries
* Dynamic DNS (DDNS) and service discovery patterns
* Split-horizon DNS for internal vs. external name resolution
* DNS-based load balancing and geographic routing (GeoDNS)

'''SSH Advanced Topics''':

* SSH tunneling: Local forwarding (<code>-L</code>), remote forwarding (<code>-R</code>), dynamic forwarding (<code>-D</code>)
* ProxyJump (<code>-J</code>) for accessing hosts through bastion servers
* SSH certificates (different from host keys) for scalable authentication
* SSH agent forwarding security considerations
* SSH config files (<code>~/.ssh/config</code>) for managing multiple hosts
* SSH as SOCKS proxy for secure browsing

'''HTTP/HTTPS Evolution''':

* HTTP/2 improvements: multiplexing, server push, header compression, binary protocol
* HTTP/3 and QUIC: UDP-based transport with built-in encryption
* WebSockets for real-time bidirectional communication
* Server-Sent Events (SSE) for server-push updates
* gRPC for efficient RPC over HTTP/2
* GraphQL as alternative to REST for flexible API queries

'''Web Server Configuration''':

* Nginx advanced reverse proxy patterns
* HAProxy for high-performance load balancing
* Load balancing algorithms: round-robin, least connections, IP hash, consistent hashing
* SSL/TLS termination best practices
* Certificate management with Let's Encrypt
* HTTP caching: proxy caching, CDN integration, cache invalidation strategies
* Security headers: HSTS, Content-Security-Policy, X-Frame-Options, CORS

'''Modern Architecture Patterns''':

* Microservices architecture: benefits and challenges
* Service mesh: Istio, Linkerd, Consul Connect
* API gateways: Kong, Ambassador, Traefik, AWS API Gateway
* Kubernetes Ingress controllers and service routing
* Serverless architecture and function-as-a-service (FaaS)
* Event-driven architectures: message queues, pub/sub patterns

'''Other Application Protocols''':

* Email protocols: SMTP for sending, IMAP for retrieval, SPF/DKIM/DMARC for authentication
* Database wire protocols: MySQL, PostgreSQL, MongoDB, Redis
* Message queue protocols: AMQP (RabbitMQ), Kafka protocol
* Monitoring and observability: Prometheus metrics, StatsD, OpenTelemetry, syslog


=== Relevant Manual Pages ===

<syntaxhighlight lang="bash">man dig # DNS query tool
man nslookup # DNS lookup utility
man host # DNS lookup utility
man ssh # SSH client
man sshd # SSH server daemon
man sshd_config # SSH server configuration
man ssh_config # SSH client configuration
man ssh-keygen # SSH key generation and management
man ssh-add # SSH agent key management
man curl # HTTP client
man wget # HTTP client alternative</syntaxhighlight>

=== Online Resources ===

'''DNS''':

* [https://www.rfc-editor.org/rfc/rfc1034 DNS RFC 1034] - Domain Names: Concepts and Facilities
* [https://www.rfc-editor.org/rfc/rfc1035 DNS RFC 1035] - Domain Names: Implementation and Specification
* [http://www.zytrax.com/books/dns/ DNS Zone File Guide] - Comprehensive DNS resource
* [https://developers.google.com/speed/public-dns Google Public DNS] - Documentation and best practices
* [https://www.cloudflare.com/learning/dns/what-is-dns/ Cloudflare 1.1.1.1] - DNS learning center

'''SSH''':

* [https://www.rfc-editor.org/rfc/rfc4251 SSH Protocol RFC 4251] - SSH Architecture
* [https://www.ssh.com/academy/ssh SSH.com Academy] - Comprehensive SSH tutorials
* [https://infosec.mozilla.org/guidelines/openssh Mozilla SSH Guidelines] - Security best practices
* [https://ed25519.cr.yp.to/ Ed25519 Benefits] - Information about Ed25519 cryptography

'''HTTP/HTTPS''':

* [https://www.rfc-editor.org/rfc/rfc7230 HTTP/1.1 RFC 7230-7235] - HTTP specification series
* [https://www.rfc-editor.org/rfc/rfc7540 HTTP/2 RFC 7540] - HTTP/2 specification
* [https://www.rfc-editor.org/rfc/rfc9114 HTTP/3 RFC 9114] - HTTP/3 specification
* [https://developer.mozilla.org/en-US/docs/Web/HTTP MDN HTTP Documentation] - Comprehensive HTTP reference
* [https://hpbn.co/ High Performance Browser Networking] - Free book by Ilya Grigorik

'''Web Servers and Reverse Proxies''':

* [https://caddyserver.com/docs/ Caddy Documentation] - Modern web server with automatic HTTPS
* [https://nginx.org/en/docs/ Nginx Documentation] - High-performance web server and reverse proxy
* [https://www.haproxy.org/documentation.html HAProxy Documentation] - Load balancer and proxy
* [https://doc.traefik.io/traefik/ Traefik Documentation] - Modern HTTP reverse proxy and load balancer

'''Security''':

* [https://owasp.org/www-project-top-ten/ OWASP Top 10] - Web application security risks
* [https://ssl-config.mozilla.org/ Mozilla SSL Configuration Generator] - TLS best practices
* [https://letsencrypt.org/docs/ Let's Encrypt] - Free TLS certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of websites

Practice Environments

* [https://overthewire.org/wargames/bandit/ OverTheWire Bandit] - Linux command-line challenges including networking
* [https://www.hackthebox.com/ HackTheBox] - Penetration testing practice with networking components
* [https://tryhackme.com/ TryHackMe] - Guided cybersecurity learning including networking modules
* [https://www.katacoda.com/courses/kubernetes Kubernetes Playground] - Practice with modern orchestration
* [https://labs.play-with-docker.com/ Docker Playground] - Free Docker environment for testing

Operating Systems

2025-12-05T15:09:50Z

Vserbu:

OS Lab 8 - Transport and Security

2025-11-28T14:49:22Z

Vserbu: /* Practice: TLS-Secured Connection */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.
* Understand the role of DNS (Domain Name System) and hostname resolution in network communication and certificate validation.



== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.

Additionally, we'll introduce a crucial component of internet infrastructure: hostname resolution. While machines communicate using IP addresses, humans prefer memorable names like "google.com" or "github.com". More importantly, security on the internet is built on these names, not IP addresses. When you visit a website with HTTPS, the server proves it controls a specific domain name (like "bank.com"), not just an IP address. In this lab, we'll use simple hostname-to-IP mappings to understand this concept before diving deeper into DNS (Domain Name System) in the next lab.



== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance



==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access
# Each machine has both an IP address (10.0.0.x) and a hostname (x.lab). This mirrors how real internet servers work—they have IP addresses for routing, but we refer to them by domain names.


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

# Configure host names
if ! grep -q "# Lab8 Configuration" /etc/hosts; then
echo "" >> /etc/hosts
echo "# Lab8 Configuration" >> /etc/hosts
echo "10.0.0.1 host.lab" >> /etc/hosts
echo "10.0.0.2 red.lab" >> /etc/hosts
echo "10.0.0.3 blue.lab" >> /etc/hosts
fi

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* Hostname entries map red.lab → 10.0.0.2, blue.lab → 10.0.0.3
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Not test connectivity using hostnames

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 blue.lab</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!



== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])

=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, attempt connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt blue.lab 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>blue.lab 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you were to attempt to connect to 10.0.0.3 instead of blue.lab, it would FAIL because of hostname mismatch.

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.



==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

OS Lab 8 - Transport and Security

2025-11-28T14:41:06Z

Vserbu: /* Environment Setup */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.
* Understand the role of DNS (Domain Name System) and hostname resolution in network communication and certificate validation.



== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.

Additionally, we'll introduce a crucial component of internet infrastructure: hostname resolution. While machines communicate using IP addresses, humans prefer memorable names like "google.com" or "github.com". More importantly, security on the internet is built on these names, not IP addresses. When you visit a website with HTTPS, the server proves it controls a specific domain name (like "bank.com"), not just an IP address. In this lab, we'll use simple hostname-to-IP mappings to understand this concept before diving deeper into DNS (Domain Name System) in the next lab.



== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance



==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access
# Each machine has both an IP address (10.0.0.x) and a hostname (x.lab). This mirrors how real internet servers work—they have IP addresses for routing, but we refer to them by domain names.


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

# Configure host names
if ! grep -q "# Lab8 Configuration" /etc/hosts; then
echo "" >> /etc/hosts
echo "# Lab8 Configuration" >> /etc/hosts
echo "10.0.0.1 host.lab" >> /etc/hosts
echo "10.0.0.2 red.lab" >> /etc/hosts
echo "10.0.0.3 blue.lab" >> /etc/hosts
fi

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* Hostname entries map red.lab → 10.0.0.2, blue.lab → 10.0.0.3
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Not test connectivity using hostnames

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 blue.lab</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!



== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])

=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt 10.0.0.3 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>10.0.0.3 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you see an error like "certificate verification failed," check:

* blue.crt Common Name matches the IP/hostname you're connecting to (we used blue.lab in the cert but are connecting to 10.0.0.3—this mismatch is OK for this lab since we're using <code>--ssl-trustfile</code>)
* ca.crt is the correct CA certificate
* blue.crt is signed by ca.crt

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.


==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

OS Lab 8 - Transport and Security

2025-11-28T14:38:57Z

Vserbu: /* Environment Setup */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.
* Understand the role of DNS (Domain Name System) and hostname resolution in network communication and certificate validation.



== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.

Additionally, we'll introduce a crucial component of internet infrastructure: hostname resolution. While machines communicate using IP addresses, humans prefer memorable names like "google.com" or "github.com". More importantly, security on the internet is built on these names, not IP addresses. When you visit a website with HTTPS, the server proves it controls a specific domain name (like "bank.com"), not just an IP address. In this lab, we'll use simple hostname-to-IP mappings to understand this concept before diving deeper into DNS (Domain Name System) in the next lab.



== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance



==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access
# Each machine has both an IP address (10.0.0.x) and a hostname (x.lab). This mirrors how real internet servers work—they have IP addresses for routing, but we refer to them by domain names.


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

# Configure host names
if ! grep -q "# Lab8 Configuration" /etc/hosts; then
echo "" >> /etc/hosts
echo "# Lab8 Configuration" >> /etc/hosts
echo "10.0.0.1 host.lab" >> /etc/hosts
echo "10.0.0.2 red.lab" >> /etc/hosts
echo "10.0.0.3 blue.lab" >> /etc/hosts
fi

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* Hostname entries map red.lab → 10.0.0.2, blue.lab → 10.0.0.3
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!



== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])

=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt 10.0.0.3 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>10.0.0.3 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you see an error like "certificate verification failed," check:

* blue.crt Common Name matches the IP/hostname you're connecting to (we used blue.lab in the cert but are connecting to 10.0.0.3—this mismatch is OK for this lab since we're using <code>--ssl-trustfile</code>)
* ca.crt is the correct CA certificate
* blue.crt is signed by ca.crt

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.


==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

OS Lab 8 - Transport and Security

2025-11-28T14:32:45Z

Vserbu: /* Introduction */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.
* Understand the role of DNS (Domain Name System) and hostname resolution in network communication and certificate validation.



== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.

Additionally, we'll introduce a crucial component of internet infrastructure: hostname resolution. While machines communicate using IP addresses, humans prefer memorable names like "google.com" or "github.com". More importantly, security on the internet is built on these names, not IP addresses. When you visit a website with HTTPS, the server proves it controls a specific domain name (like "bank.com"), not just an IP address. In this lab, we'll use simple hostname-to-IP mappings to understand this concept before diving deeper into DNS (Domain Name System) in the next lab.



== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance



==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!


== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])

=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt 10.0.0.3 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>10.0.0.3 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you see an error like "certificate verification failed," check:

* blue.crt Common Name matches the IP/hostname you're connecting to (we used blue.lab in the cert but are connecting to 10.0.0.3—this mismatch is OK for this lab since we're using <code>--ssl-trustfile</code>)
* ca.crt is the correct CA certificate
* blue.crt is signed by ca.crt

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.


==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

OS Lab 8 - Transport and Security

2025-11-28T14:32:02Z

Vserbu: /* Objectives */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.
* Understand the role of DNS (Domain Name System) and hostname resolution in network communication and certificate validation.



== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.


== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance



==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!


== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])

=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt 10.0.0.3 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>10.0.0.3 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you see an error like "certificate verification failed," check:

* blue.crt Common Name matches the IP/hostname you're connecting to (we used blue.lab in the cert but are connecting to 10.0.0.3—this mismatch is OK for this lab since we're using <code>--ssl-trustfile</code>)
* ca.crt is the correct CA certificate
* blue.crt is signed by ca.crt

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.


==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

OS Lab 8 - Transport and Security

2025-11-28T14:00:03Z

Vserbu:

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.


== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.


== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance



==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!


== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])

=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt 10.0.0.3 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>10.0.0.3 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you see an error like "certificate verification failed," check:

* blue.crt Common Name matches the IP/hostname you're connecting to (we used blue.lab in the cert but are connecting to 10.0.0.3—this mismatch is OK for this lab since we're using <code>--ssl-trustfile</code>)
* ca.crt is the correct CA certificate
* blue.crt is signed by ca.crt

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.


==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

OS Lab 8 - Transport and Security

2025-11-28T13:26:22Z

Vserbu: /* TLS: Transport Layer Security */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.


== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.


== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance



==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!


== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot or text of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump
# '''Brief Explanation''': Write 2-3 sentences explaining why you see no packets before the message (no handshake) and why this is characteristic of UDP's connectionless nature.


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])
# '''Explanation''': Write 3-4 sentences explaining:
#* What the three-way handshake accomplishes
#* Why TCP needs this handshake but UDP doesn't
#* What the sequence numbers in the handshake are used for


=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates
# '''Explanation''': Write 3-4 sentences explaining:
#* What a Certificate Authority does
#* Why we need both a private key (blue.key) and a certificate (blue.crt)
#* What the signature in the certificate proves


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt 10.0.0.3 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>10.0.0.3 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you see an error like "certificate verification failed," check:

* blue.crt Common Name matches the IP/hostname you're connecting to (we used blue.lab in the cert but are connecting to 10.0.0.3—this mismatch is OK for this lab since we're using <code>--ssl-trustfile</code>)
* ca.crt is the correct CA certificate
* blue.crt is signed by ca.crt

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.


==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot or text of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)
# '''Explanation''': Write 4-5 sentences explaining:
#* Why the tcpdump output shows gibberish instead of your actual message
#* What role the certificate (blue.crt) plays in establishing trust
#* How TLS prevents a man-in-the-middle attacker from reading your data


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

OS Lab 8 - Transport and Security

2025-11-28T13:24:46Z

Vserbu: Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Explain the fundamental differences between Connectionless (UDP) and Connection...

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain the fundamental differences between Connectionless (UDP) and Connection-Oriented (TCP) transport protocols and their appropriate use cases.
* Understand the TCP state machine and the lifecycle of connections (LISTEN, SYN_SENT, ESTABLISHED, TIME_WAIT, etc.).
* Inspect active socket states and statistics using the <code>ss</code> (socket statistics) utility to diagnose connection issues.
* Perform network service discovery using <code>nmap</code> for port scanning.
* Implement a complete Public Key Infrastructure (PKI) by generating Certificate Authorities (CAs), private keys, and signed certificates using <code>openssl</code>.
* Secure network communications using TLS (Transport Layer Security) to provide confidentiality and authenticity.
* Verify encryption effectiveness by inspecting packets with <code>tcpdump</code> to demonstrate the difference between plaintext and encrypted traffic.
* Understand the trust model of PKI and certificate chains used in modern HTTPS and secure communications.


== Introduction ==

In Lab 7, we built the foundational "plumbing" of computer networks: network interfaces, IP addresses, routing tables, and bridges. These components solve the problem of connectivity: they allow one machine to find and reach another machine on a network or across the internet. We demonstrated how the kernel routes packets from source to destination based on IP addresses.

However, there's a critical distinction we haven't addressed: machines don't really communicate with machines. More precisely, '''processes''' communicate with '''processes'''. When you browse a website, it's not just your computer talking to a server; it's your browser process talking to a web server process. When you send an email, your mail client talks to a mail server process. The question becomes: how does a packet arriving at a destination machine know which process should receive it?

This is where the Transport Layer comes into play. The transport layer solves several fundamental problems:

# '''Process Addressing''': It introduces the concept of '''ports''' to identify specific applications or services (e.g., HTTP servers typically listen on port 80, SSH on port 22, DNS on port 53).
# '''Data Transfer Semantics''': It defines '''how''' data should be transferred: reliably with error checking and retransmission (TCP) or quickly with minimal overhead (UDP).
# '''Flow Control and Congestion Management''': It prevents fast senders from overwhelming slow receivers and manages network congestion to prevent collapse.

But there's another critical problem lurking beneath the surface: '''security'''. The internet is fundamentally an untrusted network. Your packets traverse dozens of routers, switches, and network devices controlled by various organizations and potentially malicious actors. Any intermediate device can inspect, copy, or even modify your traffic. This is especially concerning when you're transmitting sensitive data like passwords, credit card numbers, or private communications.

In this lab, we move beyond basic connectivity to explore:

* How processes establish communication channels using ports and sockets
* The trade-offs between UDP's speed and TCP's reliability
* How operating systems manage connection state
* Network reconnaissance techniques (port scanning) used by both administrators and attackers
* Cryptographic foundations of secure communications (public key infrastructure)
* How TLS (Transport Layer Security) protects data in transit, forming the foundation of modern secure internet protocols like HTTPS

We'll not only establish connections between our virtual machines (Red and Blue namespaces) but also implement complete TLS encryption to prevent eavesdropping. By using <code>tcpdump</code> to inspect packets "on the wire," we'll see firsthand the difference between plaintext and encrypted communications, demonstrating why TLS has become the universal standard for web traffic.


== Prerequisites ==


=== System Requirements ===

A running instance of a Linux virtual machine with root privileges (via <code>sudo</code>). You will need terminal access, either via SSH or directly through the VM console. Multiple terminal windows will be helpful for running servers, clients, and monitoring tools simultaneously.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y nmap openssl tcpdump iproute2</syntaxhighlight>
* <code>nmap</code>: Network exploration tool and security scanner. Includes <code>ncat</code>, an implementation of <code>cat</code> over sockets with SSL/TLS support.
* <code>openssl</code>: Cryptographic toolkit for SSL/TLS, certificate generation, and various cryptographic operations.
* <code>tcpdump</code>: Command-line packet analyzer for network traffic inspection.
* <code>iproute2</code>: Modern Linux networking utilities (provides <code>ip</code>, <code>ss</code> commands).


=== Knowledge Prerequisites ===

You should be familiar with:

* Network interfaces, IP addresses, and routing from Lab 7
* Bash scripting from Lab 5 (variables, loops, functions)
* Process concepts from Lab 3 (PIDs, process execution)

You should also understand:

* What an IP address is and how packets are routed
* The concept of clients and servers
* Basic command-line text manipulation (grep, awk, cut)


== Theoretical Background ==


=== The Transport Layer: Bridging Machines and Processes ===

'''The Problem: Port Numbers and Multiplexing'''

Imagine your computer receives a packet from the internet. The IP header tells the kernel which machine the packet is for (destination IP), but once it arrives, how does the kernel know which of the potentially hundreds of running processes should receive this packet?

The solution is '''port numbers'''. A port is a 16-bit unsigned integer (range 0-65535) that identifies a specific communication endpoint on a machine. When combined with an IP address, a port creates a unique socket address (IP:PORT) that identifies a specific process on a specific machine.

Port numbers are divided into three ranges:

* '''Well-Known Ports (0-1023)''': Reserved for standard services (HTTP=80, HTTPS=443, SSH=22, DNS=53, SMTP=25). On Linux systems, binding to these ports typically requires root privileges.
* '''Registered Ports (1024-49151)''': Can be registered for specific services but are less rigidly controlled.
* '''Dynamic/Private Ports (49152-65535)''': Used for ephemeral (temporary) client-side ports when making outbound connections.

When a web browser connects to a web server, it might create a socket with local address <code>192.168.1.50:54321</code> (client's IP and a random ephemeral port) connecting to remote address <code>203.0.113.10:443</code> (server's IP and HTTPS port). The combination of (source IP, source port, destination IP, destination port, protocol) uniquely identifies a connection.

The transport layer performs '''multiplexing''' (combining multiple data streams into one network connection on the sending side) and '''demultiplexing''' (separating the combined stream back into individual streams on the receiving side based on port numbers).


==== UDP: User Datagram Protocol ====

UDP is the simpler of the two main transport protocols. Its philosophy is "fire and forget."

'''Characteristics:'''

* '''Connectionless''': No handshake or connection establishment. Just send packets (called "datagrams").
* '''Unreliable''': No delivery guarantees. Packets may arrive out of order, be duplicated, or be lost entirely.
* '''No State''': The kernel doesn't maintain connection state. Each datagram is independent.
* '''Low Overhead''': Minimal header (8 bytes) compared to TCP's 20+ bytes.
* '''Fast''': No waiting for acknowledgments or retransmissions.

'''UDP Header:'''

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Just four fields: source port, destination port, length, and an optional checksum. Compare this to TCP's much more complex header.

'''When UDP is Used:'''

* '''DNS Queries''': Fast lookups where a lost query can simply be retried.
* '''Real-time Streaming''': Video/audio where old data is useless (better to skip than wait).
* '''Gaming''': Low-latency updates where occasional packet loss is acceptable.
* '''IoT Sensors''': Simple periodic data updates where reliability is handled at application level.
* '''Broadcast/Multicast''': Sending to multiple recipients simultaneously.

'''When UDP is NOT Used:'''

* File transfers
* Financial transactions
* Remote terminal sessions
* Email delivery

UDP pushes reliability concerns to the application layer. Applications must implement their own acknowledgment, retransmission, and ordering mechanisms if needed.


==== TCP: Transmission Control Protocol ====

TCP is the workhorse of the internet. Most traffic you generate (web browsing, email, file transfers, SSH) uses TCP.

'''Characteristics:'''

* '''Connection-Oriented''': Requires explicit connection establishment (handshake) and termination.
* '''Reliable''': Guarantees that data arrives correctly and in order, using acknowledgments and retransmissions.
* '''Stateful''': The kernel maintains extensive state for each connection (sequence numbers, window sizes, timers).
* '''Stream-Oriented''': Presents data as a continuous byte stream, not individual packets. Application-level message boundaries are not preserved.
* '''Flow Control''': Prevents fast senders from overwhelming slow receivers using sliding windows.
* '''Congestion Control''': Detects network congestion and adjusts transmission rates to prevent network collapse.

'''TCP Connection Lifecycle: The State Machine'''

TCP connections go through a well-defined series of states. Understanding these states is crucial for troubleshooting network issues.

<pre>Client Side: Server Side:

CLOSED CLOSED
| |
| (bind + listen)
| |
| LISTEN
| |
(connect) |
| |
SYN_SENT -------- SYN ----------------> |
| SYN_RCVD
| <-------- SYN-ACK ----------------- |
| |
ESTABLISHED ------ ACK ---------------> ESTABLISHED
| |
| |
(data transfer happens here) |
| |
| |
(close) |
| |
FIN_WAIT_1 ------- FIN ---------------> |
| CLOSE_WAIT
| <-------- ACK -------------------- |
| |
FIN_WAIT_2 (close)
| |
| <-------- FIN -------------------- LAST_ACK
| |
TIME_WAIT ------- ACK ---------------> CLOSED
|
| (wait 2*MSL)
|
CLOSED</pre>
'''Key States Explained:'''

# '''CLOSED''': No connection exists. This is the starting and ending state.
# '''LISTEN''': Server is waiting for incoming connection requests. Socket is bound to a port.
# '''SYN_SENT''': Client has sent a SYN (synchronize) packet and is waiting for a response. This occurs immediately after calling <code>connect()</code>.
# '''SYN_RCVD''': Server has received a SYN and sent back SYN-ACK, waiting for the final ACK. Short-lived state.
# '''ESTABLISHED''': Connection is fully established and data can flow in both directions. This is where most time is spent.
# '''FIN_WAIT_1''': Active close initiated. Application called <code>close()</code>, sent FIN, waiting for ACK.
# '''FIN_WAIT_2''': Received ACK for our FIN, waiting for peer's FIN.
# '''CLOSE_WAIT''': Received FIN from peer, waiting for application to call <code>close()</code>.
# '''LAST_ACK''': Sent our FIN, waiting for final ACK.
# '''TIME_WAIT''': Both sides have closed, but socket remains in this state for 2*MSL (Maximum Segment Lifetime, typically 2-4 minutes) to ensure all packets have cleared the network. This prevents old duplicate packets from being interpreted as part of a new connection using the same port numbers.

'''The Three-Way Handshake:'''

Connection establishment (SYN → SYN-ACK → ACK) is called the "three-way handshake":

# '''Client → Server: SYN'''
#* Client sends a segment with SYN flag set and an initial sequence number (ISN)
#* Client enters SYN_SENT state
# '''Server → Client: SYN-ACK'''
#* Server responds with SYN and ACK flags set
#* Server sends its own ISN and acknowledges client's ISN+1
#* Server enters SYN_RCVD state
# '''Client → Server: ACK'''
#* Client acknowledges server's ISN+1
#* Both sides enter ESTABLISHED state
#* Data transfer can begin

This handshake synchronizes sequence numbers on both sides, allowing reliable, ordered delivery.

'''Why Three-Way? Why Not Two?'''

A two-way handshake would be susceptible to old duplicate SYN packets causing false connections. The three-way handshake ensures both sides agree on current sequence numbers before data transmission begins.

'''Connection Termination (Four-Way Handshake):'''

Either side can initiate closure:

# '''Active Closer → Passive Closer: FIN'''
# '''Passive Closer → Active Closer: ACK''' (acknowledges FIN)
# '''Passive Closer → Active Closer: FIN''' (when application closes)
# '''Active Closer → Passive Closer: ACK''' (final acknowledgment)

Sometimes steps 2 and 3 are combined (FIN+ACK in one packet) for a three-segment close.

'''TCP Segment Header:'''

TCP headers are much more complex than UDP:

<pre> 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre>
Key fields:

* '''Sequence Number''': Position of this segment's first byte in the stream
* '''Acknowledgment Number''': Next expected byte from peer
* '''Flags''': SYN, ACK, FIN, RST, PSH, URG control connection state
* '''Window''': Available receive buffer space (flow control)
* '''Checksum''': Error detection


=== Socket Statistics with ss ===

The <code>ss</code> (socket statistics) command is the modern replacement for the legacy <code>netstat</code> command. It's faster and more feature-rich.

Common usage:

<syntaxhighlight lang="bash">ss -tuna # TCP, UDP, numeric, all states
ss -tln # TCP listening sockets with numeric ports
ss -tapn # TCP all states, show process names</syntaxhighlight>
Options:

* <code>-t</code>: TCP sockets
* <code>-u</code>: UDP sockets
* <code>-l</code>: Listening sockets only
* <code>-a</code>: All states (listening and non-listening)
* <code>-n</code>: Don't resolve service names (show port numbers)
* <code>-p</code>: Show process using socket
* <code>-e</code>: Extended information
* <code>-m</code>: Memory usage

Example output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080
TIME-WAIT 0 0 10.0.0.2:45680 10.0.0.3:8080</pre>
Understanding the fields:

* '''State''': Current TCP state
* '''Recv-Q''': Bytes in receive queue (not yet read by application)
* '''Send-Q''': Bytes in send queue (not yet acknowledged by peer)
* '''Local Address:Port''': This machine's socket address
* '''Peer Address:Port''': Remote machine's socket address

Non-zero Recv-Q might indicate the application is slow to read data. Non-zero Send-Q might indicate network congestion or a slow receiver.


=== Network Security Fundamentals ===

The Threat Model: Man-in-the-Middle (MITM)

Consider the network topology from Lab 7:

<pre>[Red NS] ←→ [Bridge] ←→ [Blue NS]
↑
[Host]</pre>
The host has interfaces connected to the bridge and can see all traffic between Red and Blue. In a real network, this "middle position" might be occupied by:

* Your ISP's routers
* Corporate proxy servers
* Public WiFi access points
* Government surveillance equipment
* Malicious actors who've compromised network infrastructure

A Man-in-the-Middle attacker can:

# '''Eavesdrop''': Read all plaintext data (passwords, messages, documents)
# '''Modify''': Alter data in transit (change bank account numbers, inject malware)
# '''Impersonate''': Pretend to be one side of the communication

This is why encryption is essential for any sensitive communication.


==== Cryptography Basics ====

Modern secure communications rely on a combination of '''symmetric''' and '''asymmetric''' cryptography.

'''Symmetric Encryption (Secret Key Cryptography):'''

* Same key used for encryption and decryption
* Fast and efficient
* Problem: How do you securely share the key?
* Examples: AES, ChaCha20

'''Asymmetric Encryption (Public Key Cryptography):'''

* Key pair: public key (can be shared) and private key (must be kept secret)
* Data encrypted with public key can only be decrypted with private key
* Slow compared to symmetric encryption
* Solves key distribution problem
* Examples: RSA, Elliptic Curve (ECDSA, Ed25519)

'''Digital Signatures:'''

* Used to verify authenticity and integrity
* Sender creates a signature using their private key
* Receiver verifies using sender's public key
* Proves the sender owns the private key and data hasn't been tampered with

'''Hash Functions:'''

* One-way functions that produce fixed-size output (digest) from arbitrary input
* Same input always produces same output
* Computationally infeasible to find two inputs with same output (collision resistance)
* Examples: SHA-256, SHA-3


==== TLS: Transport Layer Security ====

TLS (formerly SSL) is the protocol that secures most internet traffic today. It provides:

# '''Confidentiality''': Data is encrypted so eavesdroppers see only gibberish
# '''Integrity''': Data cannot be modified without detection
# '''Authentication''': Verify you're talking to the correct server (via certificates)

'''TLS Handshake (Simplified):'''

<pre>Client Server

ClientHello ----------------------------------------→
(supported ciphers, TLS versions, random nonce)

←---------------------- ServerHello
(chosen cipher, TLS version, random nonce)
Certificate
(server's public key + CA signature)
ServerKeyExchange
ServerHelloDone

ClientKeyExchange ------------------------------------→
(pre-master secret encrypted with server's public key)
ChangeCipherSpec
Finished

←--------------- ChangeCipherSpec
Finished

[Encrypted Application Data] ←----------------→ [Encrypted Application Data]</pre>
Key steps:

# '''Negotiation''': Agree on TLS version and cipher suite
# '''Authentication''': Server presents certificate (sometimes client does too)
# '''Key Exchange''': Establish shared encryption keys using asymmetric crypto
# '''Encryption''': Switch to symmetric encryption for data transfer

In order to minimize overhead, the asymmetric crypto is only used to establish a session key. Then fast symmetric encryption is used for the actual data.

'''Why Both?'''

* Asymmetric encryption solves the key distribution problem
* Symmetric encryption provides fast data encryption
* Together they provide security and performance


==== Public Key Infrastructure (PKI) ====

PKI is the system of trust that underlies secure internet communications.

'''Components:'''

# '''Certificate Authority (CA)''': A trusted third party that signs certificates. Major CAs include Let's Encrypt, DigiCert, GlobalSign. Your operating system and browser come with a pre-installed list of trusted root CAs.
# '''Certificate''': A document binding a public key to an identity (domain name, organization). Contains:
#* Subject (who the certificate is for)
#* Issuer (which CA signed it)
#* Public key
#* Validity period (not before / not after dates)
#* Digital signature (from CA)
# '''Private Key''': Kept secret by the certificate owner. Used to prove ownership and establish secure connections.
# '''Certificate Signing Request (CSR)''': A request to a CA saying "Please sign a certificate for my public key and domain."

'''Trust Chain:'''

<pre>Root CA (self-signed, in browser's trust store)
↓ signs
Intermediate CA (signed by Root CA)
↓ signs
End-Entity Certificate (your server, signed by Intermediate CA)</pre>
When you connect to <code>https://example.com</code>:

# Server sends its certificate
# Your browser checks: Is this certificate signed by a CA I trust?
# Browser walks the chain: End-entity ← Intermediate ← Root
# If Root CA is in browser's trust store, certificate is trusted
# Browser verifies certificate is for the correct domain (example.com)
# Browser verifies certificate hasn't expired
# If all checks pass, secure connection established

'''Self-Signed Certificates:'''

In this lab, we create self-signed certificates (the CA signs its own certificate). This is fine for testing, but browsers will show warnings in production because the CA isn't in their trust store. Real websites use certificates from trusted CAs.

Port Scanning and Network Reconnaissance

Port scanning is the process of probing a target system to discover which ports are open (have services listening). This is used by:

* System administrators for inventory and auditing
* Security researchers for vulnerability assessment
* Attackers for reconnaissance (first step in many attacks)

'''nmap Basics:'''

<syntaxhighlight lang="bash">nmap -p 22 10.0.0.3 # Scan port 22 on specific IP
nmap -p 1-1000 10.0.0.3 # Scan ports 1-1000
nmap -p- 10.0.0.3 # Scan all 65535 ports
nmap 10.0.0.0/24 # Scan all hosts in subnet
nmap -sV 10.0.0.3 # Service version detection
nmap -O 10.0.0.3 # OS fingerprinting</syntaxhighlight>
'''Scan Types:'''

* '''TCP Connect Scan''' (<code>-sT</code>): Completes full three-way handshake. Most reliable but also most detectable.
* '''SYN Scan''' (<code>-sS</code>, default for root): Sends SYN, waits for SYN-ACK, then sends RST instead of ACK. "Half-open" scan, stealthier.
* '''UDP Scan''' (<code>-sU</code>): Slower, less reliable, but necessary for UDP services.

'''Port States:'''

* '''Open''': Service actively accepting connections
* '''Closed''': No service, but port is reachable (responds with RST)
* '''Filtered''': Firewall or filter blocking access (no response or ICMP unreachable)

Only scan systems you own or have explicit permission to scan. Unauthorized scanning may violate computer crime laws.


=== The Future: QUIC and HTTP/3 ===

TCP has served the internet well since the 1970s, but it has limitations that become apparent in modern, high-latency networks.

'''TCP's Problems:'''

# '''Head-of-Line Blocking''': TCP provides a single ordered byte stream. If one packet is lost, all subsequent packets (even for unrelated data) must wait for retransmission. In HTTP/2, a single lost packet blocks all simultaneous downloads.
# '''Handshake Latency''': TCP three-way handshake + TLS handshake requires 2-3 round trips before data transfer begins. On high-latency connections (satellite, mobile), this adds seconds of delay.
# '''Ossification''': TCP is implemented in operating system kernels. Deploying new features (like improved congestion control) requires OS updates on billions of devices—essentially impossible.

'''QUIC (Quick UDP Internet Connections):'''

QUIC is a new transport protocol developed by Google, now standardized as RFC 9000. It's the foundation of HTTP/3.

Key innovations:

* '''Built on UDP''': Implemented in userspace, not kernel. Fast iteration and deployment.
* '''Integrated TLS 1.3''': Encryption is mandatory and built-in, not layered on top.
* '''Multiple Streams''': Supports many independent streams in one connection. Loss in one stream doesn't block others.
* '''0-RTT Connection Resumption''': Returning clients can send data in the first packet (zero round trips).
* '''Connection Migration''': Connection survives IP address changes (e.g., switching from WiFi to cellular).

QUIC implements reliability, congestion control, and flow control in userspace, giving the protocol designers much more flexibility than kernel-based TCP.

'''Adoption:'''

As of 2024, QUIC/HTTP/3 is used by:

* Google services (Search, YouTube, Gmail)
* Facebook/Meta
* Cloudflare
* Major CDNs

Most modern browsers support HTTP/3. It's particularly beneficial for mobile users and high-latency scenarios.


== Environment Setup ==

We need the topology from Lab 7 (Red, Blue, and a Bridge connecting them). To ensure a clean, consistent environment, we'll use a setup script.

Understanding the Setup Script

The script creates the following topology:

<pre> [Host: 10.0.0.1]
|
| (br-lab bridge)
|
+-------+-------+
| |
[Red: 10.0.0.2] [Blue: 10.0.0.3]</pre>
Key operations:

# Clean up any existing namespaces and bridges from previous labs
# Create a Linux bridge (<code>br-lab</code>) acting as a virtual switch
# Create two network namespaces (<code>red</code> and <code>blue</code>)
# Create veth pairs connecting each namespace to the bridge
# Assign IP addresses and routes
# Enable NAT for internet access


=== Step 1: Create the Setup Script ===

Create <code>lab8_setup.sh</code> with the following content:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

if [ "$EUID" -ne 0 ]; then
echo "Please run as root (use sudo)"
exit 1
fi

echo "[*] Cleaning up old environment..."
ip netns delete red 2>/dev/null || true
ip netns delete blue 2>/dev/null || true
ip link delete br-lab 2>/dev/null || true

echo "[*] Creating Bridge..."
ip link add br-lab type bridge
ip link set br-lab up
ip addr add 10.0.0.1/24 dev br-lab

echo "[*] Creating Namespaces..."
ip netns add red
ip netns add blue

echo "[*] Wiring Red..."
ip link add veth-red type veth peer name veth-red-br
ip link set veth-red-br master br-lab
ip link set veth-red-br up
ip link set veth-red netns red
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec red ip route add default via 10.0.0.1

echo "[*] Wiring Blue..."
ip link add veth-blue type veth peer name veth-blue-br
ip link set veth-blue-br master br-lab
ip link set veth-blue-br up
ip link set veth-blue netns blue
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up
ip netns exec blue ip route add default via 10.0.0.1

echo "[*] Enabling NAT on Host..."
sysctl -w net.ipv4.ip_forward=1 > /dev/null

# Determine internet-facing interface
IFACE=$(ip route get 8.8.8.8 | grep -oP 'dev \K\S+')
echo "[*] Detected internet interface: $IFACE"

# Configure NAT (idempotent - won't fail if already exists)
nft add table ip nat 2>/dev/null || true
nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; } 2>/dev/null || true
nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "$IFACE" masquerade 2>/dev/null || true

echo ">>> Setup Complete"
echo " Red: 10.0.0.2"
echo " Blue: 10.0.0.3"
echo " Host: 10.0.0.1"</syntaxhighlight>
'''Script Explanation:'''

* <code>set -euo pipefail</code>: Exit immediately if any command fails
* <code>[ "$EUID" -ne 0 ]</code>: Check if running as root (EUID = Effective User ID)
* <code>2>/dev/null || true</code>: Suppress error messages and don't fail if cleanup targets don't exist
* <code>ip route get 8.8.8.8</code>: A way to determine which interface routes to the internet
* <code>grep -oP 'dev \K\S+'</code>: Extract just the interface name
* NAT commands use <code>|| true</code> to be idempotent (can run multiple times safely)


=== Step 2: Make the Script Executable and Run It ===

<syntaxhighlight lang="bash">chmod +x lab8_setup.sh
sudo ./lab8_setup.sh</syntaxhighlight>
Expected output:

<pre>[*] Cleaning up old environment...
[*] Creating Bridge...
[*] Creating Namespaces...
[*] Wiring Red...
[*] Wiring Blue...
[*] Enabling NAT on Host...
[*] Detected internet interface: eth0
[✓] Setup Complete
Red: 10.0.0.2
Blue: 10.0.0.3
Host: 10.0.0.1</pre>

=== Step 3: Verify the Setup ===

Test connectivity between Red and Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 10.0.0.3</syntaxhighlight>
Test internet access from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 2 8.8.8.8</syntaxhighlight>
Both should succeed. If they fail:

* Check that the setup script completed without errors
* Verify interfaces are UP: <code>ip link show br-lab</code>, <code>sudo ip netns exec red ip link</code>
* Verify routes: <code>sudo ip netns exec red ip route show</code>
* Verify NAT rules: <code>sudo nft list ruleset</code>

You're now ready to begin the hands-on exercises!


== Hands-on Exercises ==

These exercises build progressively, demonstrating the differences between UDP and TCP, socket state management, and finally securing communications with TLS encryption.


=== Exercise A: UDP Communication (The Connectionless Message) ===


==== Theory: UDP's Simplicity ====

UDP is the "postcards" of the internet. You write a message, put on an address, and drop it in the mailbox. You hope it arrives, but you don't get confirmation. There's no handshake, no connection establishment—just send data and hope for the best.

This simplicity has advantages:

* '''Low latency''': No handshake delay
* '''No connection state''': Server can handle many clients with minimal resources
* '''Multicast/broadcast capable''': Can send to multiple recipients simultaneously

For this exercise, we'll send a message from Red to Blue using UDP and observe the traffic with <code>tcpdump</code>. Because UDP is connectionless, you'll see the data appear immediately on the wire without any preceding handshake packets.


==== Practice: Sending UDP Messages ====

We'll use three terminal windows:

# '''Terminal 1 (Host)''': The "wiretapper" watching traffic on the bridge
# '''Terminal 2 (Blue)''': The UDP server listening for messages
# '''Terminal 3 (Red)''': The UDP client sending messages

'''Step 1: Start the Wiretapper'''

In Terminal 1 on the host, start capturing UDP traffic on port 9000:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X udp port 9000</syntaxhighlight>
Let's break down this command:

* <code>-i br-lab</code>: Capture on the bridge interface (where we can see traffic between Red and Blue)
* <code>-X</code>: Display packet contents in both hex and ASCII
* <code>udp port 9000</code>: BPF (Berkeley Packet Filter) expression matching UDP packets with source or destination port 9000

You should see:

<pre>tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lab, link-type EN10MB (Ethernet), capture size 262144 bytes</pre>
Leave this running. It's now waiting to capture packets.

'''Step 2: Start the UDP Server'''

In Terminal 2, start a UDP listener in the Blue namespace:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -u -l -p 9000</syntaxhighlight>
Command breakdown:

* <code>ip netns exec blue</code>: Run command in Blue's namespace
* <code>ncat</code>: Network cat implementation (from nmap package)
* <code>-u</code>: Use UDP instead of TCP
* <code>-l</code>: Listen mode (act as server)
* <code>-p 9000</code>: Listen on port 9000

The command appears to hang: this is correct. It's waiting for incoming datagrams.

'''Step 3: Start the UDP Client'''

In Terminal 3, connect to the Blue server from Red:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat -u 10.0.0.3 9000</syntaxhighlight>
Command breakdown:

* <code>ncat -u 10.0.0.3 9000</code>: Connect to 10.0.0.3 on port 9000 using UDP

The terminal is now ready for input. You can type messages.

'''Step 4: Send a Message'''

In Terminal 3 (Red client), type:

<pre>Hello UDP World</pre>
Press Enter.

'''Step 5: Observe the Results'''

* '''Terminal 2 (Blue server)''': Should display "Hello UDP World"
* '''Terminal 1 (tcpdump)''': Should show the captured packet

The tcpdump output will look something like this:

<pre>15:42:18.123456 IP 10.0.0.2.45678 > 10.0.0.3.9000: UDP, length 16
0x0000: 4500 002c 1234 4000 4011 abcd 0a00 0002 E..,..@.@.......
0x0010: 0a00 0003 b26e 2328 0018 5678 4865 6c6c .....n#(..VxHell
0x0020: 6f20 5544 5020 576f 726c 640a o.UDP.World.</pre>
Key observations:

* Source: <code>10.0.0.2.45678</code> (Red, ephemeral port)
* Destination: <code>10.0.0.3.9000</code> (Blue, our server port)
* Protocol: UDP
* You can see "Hello UDP World" in the ASCII column on the right

'''Step 6: Critical Analysis'''

Look carefully at the tcpdump output. Count the packets:

* You should see exactly ONE packet—the data packet
* There were NO packets before the message (no handshake)
* There were NO acknowledgment packets after the message

Try sending more messages in Terminal 3:

<pre>Message two
Third message</pre>
Each appears immediately in Terminal 2 and Terminal 1 as a separate UDP datagram.

'''Step 7: Cleanup'''

Press Ctrl+C in all three terminals to stop the processes.

Understanding What Happened

When you pressed Enter in Terminal 3:

# Red's <code>ncat</code> process wrote "Hello UDP World\n" to a UDP socket
# Red's kernel wrapped this in a UDP datagram (8-byte UDP header + data)
# Red's kernel wrapped the UDP datagram in an IP packet (20-byte IP header + UDP datagram)
# Red's kernel wrapped the IP packet in an Ethernet frame (14-byte Ethernet header + IP packet)
# Frame sent out veth-red interface
# Frame traversed veth pair to bridge
# Bridge forwarded frame to veth-blue-br
# Frame arrived at Blue's veth-blue interface
# Blue's kernel unwrapped layers and delivered payload to <code>ncat</code> process listening on port 9000
# Blue's <code>ncat</code> wrote payload to stdout

All of this happened in microseconds, with no connection setup or teardown.


==== Deliverable A ====

Provide the following:

# '''tcpdump Output''': Screenshot or text of the tcpdump output showing at least one UDP packet. The output must clearly show:
#* Source IP and port (Red, ephemeral)
#* Destination IP and port (Blue, 9000)
#* The plaintext message in the hex/ASCII dump
# '''Brief Explanation''': Write 2-3 sentences explaining why you see no packets before the message (no handshake) and why this is characteristic of UDP's connectionless nature.


=== Exercise B: TCP Communication and Socket State Inspection ===


==== Theory: TCP's Statefulness ====

Unlike UDP, TCP maintains connection state. Before any data flows, both sides must agree to communicate (handshake). The kernel tracks this state throughout the connection's lifetime.

In this exercise, we'll:

# Start a TCP server in Blue
# Use <code>nmap</code> to discover the open port (simulating reconnaissance)
# Capture the three-way handshake with <code>tcpdump</code>
# Establish a connection from Red
# Inspect the kernel's socket state table to see the ESTABLISHED connection
# Observe the four-way handshake when closing

This demonstrates TCP's stateful nature and introduces important diagnostic tools.


==== Practice: TCP Connection Lifecycle ====

'''Step 1: Start the TCP Server'''

In Terminal 1, start a TCP listener in Blue on port 8080:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat -l -p 8080</syntaxhighlight>
Note the absence of <code>-u</code> flag—this defaults to TCP mode.

The command waits for connections. In TCP, the server must be listening before clients can connect (unlike UDP where you can send to a port that isn't listening).

'''Step 2: Verify Server is Listening'''

In Terminal 2, check Blue's listening sockets:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tln</syntaxhighlight>
Command breakdown:

* <code>ss</code>: Socket statistics utility
* <code>-t</code>: Show TCP sockets
* <code>-l</code>: Show listening sockets only
* <code>-n</code>: Numeric output (don't resolve port names)

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*</pre>
This shows:

* '''State''': LISTEN (waiting for connections)
* '''Recv-Q''': 0 (no data in receive queue)
* '''Send-Q''': 128 (this is actually the backlog—max pending connections)
* '''Local Address:Port''': 0.0.0.0:8080 (listening on all interfaces)
* '''Peer Address:Port''': 0.0.0.0:* (no peer yet, not connected)

The <code>0.0.0.0</code> address means "any interface"—the server will accept connections on any IP address belonging to this machine.

'''Step 3: Port Reconnaissance with nmap'''

In Terminal 2, scan Blue from Red to discover open ports:

<syntaxhighlight lang="bash">sudo ip netns exec red nmap -p 8080 10.0.0.3</syntaxhighlight>
Command breakdown:

* <code>nmap</code>: Network exploration tool
* <code>-p 8080</code>: Scan only port 8080
* <code>10.0.0.3</code>: Target IP (Blue)

Expected output:

<pre>Starting Nmap 7.93 ( https://nmap.org )
Nmap scan report for 10.0.0.3
Host is up (0.000050s latency).

PORT STATE SERVICE
8080/tcp open http-proxy

Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds</pre>
Key information:

* Port 8080 is '''open''' (accepting connections)
* Nmap identified it as potentially being "http-proxy" based on common port conventions (though it's actually just our ncat listener)
* Latency is very low (microseconds) because everything is local

'''How did nmap determine the port is open?''' nmap sent a SYN packet. Blue responded with SYN-ACK (indicating willingness to connect). nmap then sent RST to abort the connection. This "SYN scan" is less noisy than completing the full handshake.

'''Step 4: Capture the Three-Way Handshake'''

In Terminal 3, start capturing TCP control packets (SYN, FIN, RST) on the bridge:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"</syntaxhighlight>
This is a complex BPF filter. Let's decode it:

* <code>tcp[tcpflags]</code>: Access the TCP flags byte in the header
* <code>& (tcp-syn|tcp-fin|tcp-rst)</code>: Bitwise AND with mask for SYN, FIN, or RST flags
* <code>!= 0</code>: Match if any of these flags are set

This captures connection establishment (SYN) and termination (FIN, RST) packets, filtering out normal data packets.

Leave this running.

'''Step 5: Establish a Connection'''

In Terminal 2, connect from Red to Blue:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat 10.0.0.3 8080</syntaxhighlight>
This time we're not using <code>-l</code> (this is the client side) and not using <code>-u</code> (defaulting to TCP).

'''Step 6: Observe the Handshake'''

In Terminal 3 (tcpdump), you should see three packets:

<pre>16:15:32.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [S], seq 1234567890, win 65535
16:15:32.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [S.], seq 9876543210, ack 1234567891, win 65535
16:15:32.123478 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack 9876543211, win 65535</pre>
Let's analyze each packet:

'''Packet 1: SYN'''

* Source: Red (10.0.0.2, ephemeral port 45678)
* Destination: Blue (10.0.0.3, port 8080)
* Flags: <code>[S]</code> (SYN only)
* Sequence number: Red's initial sequence number (ISN)
* This is Red saying: "I want to establish a connection. My starting sequence number is 1234567890."

'''Packet 2: SYN-ACK'''

* Source: Blue (10.0.0.3, port 8080)
* Destination: Red (10.0.0.2, port 45678)
* Flags: <code>[S.]</code> (SYN + ACK)
* Sequence number: Blue's ISN
* Acknowledgment: Red's ISN + 1
* This is Blue saying: "I accept the connection. My starting sequence number is 9876543210, and I'm ready to receive byte 1234567891 from you."

'''Packet 3: ACK'''

* Source: Red
* Destination: Blue
* Flags: <code>[.]</code> (ACK only, represented as a dot)
* Acknowledgment: Blue's ISN + 1
* This is Red saying: "Acknowledged. I'm ready to receive byte 9876543211 from you."

The connection is now '''ESTABLISHED''' on both sides.

'''Step 7: Inspect Socket State'''

In Terminal 4 (new terminal), check Blue's socket table:

<syntaxhighlight lang="bash">sudo ip netns exec blue ss -tna</syntaxhighlight>
Adding the <code>-a</code> flag shows all states (not just listening).

Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
ESTAB 0 0 10.0.0.3:8080 10.0.0.2:45678</pre>
Now we see two entries:

# The original LISTEN socket (still waiting for additional connections)
# A new ESTAB (ESTABLISHED) socket representing the connected client

The ESTABLISHED socket shows the full four-tuple:

* Local: 10.0.0.3:8080 (Blue's IP and the server port)
* Peer: 10.0.0.2:45678 (Red's IP and Red's ephemeral port)

Also check from Red's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
Expected output:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
Red sees one ESTABLISHED connection. Notice the local and peer addresses are swapped from Blue's perspective—same connection, different viewpoint.

'''Step 8: Data Transfer'''

The connection is established. Type a message in Terminal 2 (Red client):

<pre>Testing TCP Connection</pre>
Press Enter. The message should appear in Terminal 1 (Blue server).

Now type a response in Terminal 1:

<pre>Message received</pre>
Press Enter. It should appear in Terminal 2.

TCP provides '''bidirectional''' communication over a single connection.

'''Step 9: Connection Termination'''

Press Ctrl+D (EOF, end of file) in Terminal 2 (Red client). This closes Red's side of the connection.

In Terminal 3 (tcpdump), you should see the four-way handshake:

<pre>16:20:15.123456 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [F.], seq ..., ack ...
16:20:15.123467 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [.], ack ...
16:20:15.123478 IP 10.0.0.3.8080 > 10.0.0.2.45678: Flags [F.], seq ..., ack ...
16:20:15.123489 IP 10.0.0.2.45678 > 10.0.0.3.8080: Flags [.], ack ...</pre>
'''Packet 1: FIN from Red'''

* Red says: "I'm done sending data. I'm closing my side of the connection."

'''Packet 2: ACK from Blue'''

* Blue acknowledges Red's FIN: "I received your close notification."

'''Packet 3: FIN from Blue'''

* Blue says: "I'm also done. I'm closing my side."

'''Packet 4: ACK from Red'''

* Red acknowledges Blue's FIN: "Confirmed. Connection fully closed."

Immediately after this, check the socket state:

<syntaxhighlight lang="bash">sudo ip netns exec red ss -tna</syntaxhighlight>
You might see:

<pre>State Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT 0 0 10.0.0.2:45678 10.0.0.3:8080</pre>
The connection enters TIME-WAIT state for typically 60 seconds to ensure all packets have cleared the network. This prevents old duplicate packets from being misinterpreted as part of a new connection using the same port numbers.

After the timeout, the connection disappears entirely from the socket table.

'''Step 10: Compare with UDP'''

Think about the differences:

* '''UDP''': No handshake, no state, no acknowledgments, just send data
* '''TCP''': Three-way handshake to establish, state tracking during connection, four-way handshake to terminate

TCP's complexity provides reliability at the cost of overhead and latency.

Understanding TCP State Transitions

The states we observed:

# '''LISTEN''' → Waiting for incoming connections
# '''SYN_SENT''' → (We didn't see this as client because transition was fast)
# '''ESTABLISHED''' → Active connection, data transfer phase
# '''FIN_WAIT_1''' → (Brief state during close)
# '''FIN_WAIT_2''' → (Brief state during close)
# '''TIME_WAIT''' → Ensuring clean shutdown

In production environments, you might see:

* Many TIME_WAIT connections after a load spike (normal)
* Connections stuck in SYN_SENT (peer not responding)
* Many CLOSE_WAIT (application not properly closing connections—potential resource leak)


==== Deliverable B ====

Provide the following:

# '''ss Output''': The output of <code>sudo ip netns exec blue ss -tna</code> showing both the LISTEN socket and the ESTABLISHED connection. Clearly label which line is which.
# '''tcpdump Output''': The captured three-way handshake showing:
#* Packet 1: SYN (Flags [S])
#* Packet 2: SYN-ACK (Flags [S.])
#* Packet 3: ACK (Flags [.])
# '''Explanation''': Write 3-4 sentences explaining:
#* What the three-way handshake accomplishes
#* Why TCP needs this handshake but UDP doesn't
#* What the sequence numbers in the handshake are used for


=== Exercise C: Public Key Infrastructure (Creating a Certificate Authority) ===


==== Theory: The Trust Problem ====

Encryption solves the confidentiality problem. But it creates a new problem: '''authentication'''. How do you know you're talking to the real Blue server and not an attacker pretending to be Blue?

Consider this attack scenario:

# Red wants to connect to Blue
# Attacker intercepts the connection
# Attacker establishes two connections: Attacker↔Red and Attacker↔Blue
# Attacker decrypts messages from Red, reads them, re-encrypts, and forwards to Blue
# Neither Red nor Blue realizes they're talking through a middleman

This is a classic Man-in-the-Middle (MITM) attack. Encryption alone doesn't prevent it.

'''PKI solves this with:'''

# '''Certificates''': Digital documents binding a public key to an identity (domain name, organization)
# '''Digital Signatures''': Certificates are signed by a trusted Certificate Authority (CA)
# '''Trust Anchors''': Your system comes with a pre-installed list of trusted root CAs

When Red connects to Blue:

# Blue sends its certificate
# Red checks: Is this certificate signed by a CA I trust?
# Red verifies the certificate is for the correct domain/identity
# Red verifies the certificate hasn't expired
# If all checks pass, Red uses the public key from the certificate to establish encryption

The attacker can't forge a certificate signed by a trusted CA (they don't have the CA's private key).

'''Certificate Components:'''

A certificate contains:

* '''Subject''': Who the certificate is for (e.g., <code>CN=blue.lab</code>, Common Name)
* '''Issuer''': Who signed it (e.g., <code>CN=root-ca</code>)
* '''Public Key''': The subject's public key
* '''Validity Period''': Not Before and Not After dates
* '''Signature''': CA's digital signature over all the above

'''X.509 Standard:'''

Certificates use the X.509 format, an ITU-T standard. The format is binary (DER encoding) but often converted to text (PEM encoding) for easier handling. PEM format looks like:

<pre>-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJAKL0h...
(many lines of Base64-encoded data)
-----END CERTIFICATE-----</pre>

==== Practice: Building Your Own PKI ====

In production, you'd obtain certificates from a public CA like Let's Encrypt, DigiCert, or GlobalSign. For this lab, we'll create our own CA and sign our own certificates. This gives insight into how PKI works internally.

'''Step 1: Create a Working Directory'''

<syntaxhighlight lang="bash">mkdir -p pki
cd pki</syntaxhighlight>
This directory will contain all our keys and certificates. In production, private keys would be stored with strict access controls (chmod 600).

'''Step 2: Generate the Certificate Authority'''

First, we create the root of our trust hierarchy—the CA itself.

<syntaxhighlight lang="bash">openssl req -new -x509 -days 365 -nodes \
-subj "/C=RO/ST=Bucharest/L=Lab/O=MyCA/CN=root-ca" \
-keyout ca.key -out ca.crt</syntaxhighlight>
Let's break down this complex command:

* <code>openssl req</code>: Certificate request utility
* <code>-new</code>: Generate a new certificate request
* <code>-x509</code>: Output a self-signed certificate instead of a CSR
* <code>-days 365</code>: Certificate valid for 365 days
* <code>-nodes</code>: Don't encrypt the private key (no DES, "nodes" = no DES). In production, you'd protect the CA key with a passphrase.
* <code>-subj</code>: Certificate subject (identity):
** <code>C=RO</code>: Country (Romania)
** <code>ST=Bucharest</code>: State/Province
** <code>L=Lab</code>: Locality
** <code>O=MyCA</code>: Organization
** <code>CN=root-ca</code>: Common Name (identifies this CA)
* <code>-keyout ca.key</code>: Write private key to this file
* <code>-out ca.crt</code>: Write certificate to this file

This creates two files:

* '''ca.key''': The CA's private key. KEEP THIS SECRET. Anyone with this key can sign certificates that your system will trust.
* '''ca.crt''': The CA's self-signed certificate. This is the "trust anchor" that clients will use to verify other certificates.

'''Step 3: Inspect the CA Certificate'''

Let's see what we created:

<syntaxhighlight lang="bash">openssl x509 -in ca.crt -text -noout</syntaxhighlight>
Command breakdown:

* <code>openssl x509</code>: Certificate utility
* <code>-in ca.crt</code>: Input file
* <code>-text</code>: Output human-readable text
* <code>-noout</code>: Don't output the certificate itself (just the decoded text)

Expected output (abbreviated):

<pre>Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12345678901234567890
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Validity
Not Before: Nov 1 10:00:00 2024 GMT
Not After : Nov 1 10:00:00 2025 GMT
Subject: C=RO, ST=Bucharest, L=Lab, O=MyCA, CN=root-ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:d4:7a:...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier: ...
X509v3 Authority Key Identifier: ...
X509v3 Basic Constraints: critical
CA:TRUE</pre>
Key observations:

* '''Issuer == Subject''': This is self-signed (the CA signed its own certificate)
* '''Validity''': 365 days from creation
* '''Public Key''': 2048-bit RSA key
* '''CA:TRUE''': This certificate can sign other certificates

'''Step 4: Generate the Server's Private Key'''

Now we create a private key for the Blue server:

<syntaxhighlight lang="bash">openssl genrsa -out blue.key 2048</syntaxhighlight>
Command breakdown:

* <code>openssl genrsa</code>: Generate RSA private key
* <code>-out blue.key</code>: Output file
* <code>2048</code>: Key size in bits (2048 is standard; 4096 for higher security)

This generates blue.key, a 2048-bit RSA private key. This file must be kept secret. Anyone with this key can impersonate the Blue server.

'''Step 5: Generate a Certificate Signing Request (CSR)'''

The server creates a CSR to ask the CA to sign a certificate:

<syntaxhighlight lang="bash">openssl req -new -key blue.key \
-subj "/C=RO/ST=Bucharest/L=Lab/O=BlueServer/CN=blue.lab" \
-out blue.csr</syntaxhighlight>
Command breakdown:

* <code>openssl req -new</code>: Create a new certificate request
* <code>-key blue.key</code>: Use this private key
* <code>-subj</code>: Certificate subject:
** <code>CN=blue.lab</code>: Common Name (this should match the domain name clients use to connect)
* <code>-out blue.csr</code>: Output CSR file

The CSR contains:

* The server's public key (derived from blue.key)
* The desired subject (identity)
* A signature proving the requester possesses the private key

'''Why a CSR?''' In production, you'd send the CSR to a public CA. The CA verifies your identity (sometimes requiring domain ownership verification, sometimes requiring extensive documentation). Once satisfied, the CA signs your CSR, creating a certificate. You never share your private key with the CA.

'''Step 6: Sign the Certificate (Act as CA)'''

Now we act as the CA and sign Blue's CSR:

<syntaxhighlight lang="bash">openssl x509 -req -in blue.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out blue.crt -days 365</syntaxhighlight>
Command breakdown:

* <code>openssl x509 -req</code>: Sign a certificate request
* <code>-in blue.csr</code>: Input CSR
* <code>-CA ca.crt</code>: CA's certificate
* <code>-CAkey ca.key</code>: CA's private key (this is why we keep it secret)
* <code>-CAcreateserial</code>: Create a serial number file (ca.srl) to track issued certificates
* <code>-out blue.crt</code>: Output signed certificate
* <code>-days 365</code>: Certificate valid for 365 days

This creates blue.crt, signed by our CA. The signature proves the CA vouches for the binding between the public key and the identity "blue.lab."

'''Step 7: Inspect the Server Certificate'''

<syntaxhighlight lang="bash">openssl x509 -in blue.crt -text -noout</syntaxhighlight>
Key observations:

* '''Issuer''': CN=root-ca (signed by our CA)
* '''Subject''': CN=blue.lab (the server's identity)
* '''Issuer ≠ Subject''': This is NOT self-signed; it's signed by the CA
* '''Signature''': Contains the CA's cryptographic signature

'''Step 8: Verify the Certificate Chain'''

Clients will verify that blue.crt is signed by ca.crt:

<syntaxhighlight lang="bash">openssl verify -CAfile ca.crt blue.crt</syntaxhighlight>
Expected output:

<pre>blue.crt: OK</pre>
This confirms the certificate chain is valid. If we modified blue.crt or used a different CA, verification would fail.

'''Step 9: File Inventory'''

List the files we created:

<syntaxhighlight lang="bash">ls -lh pki</syntaxhighlight>
Expected output:

<pre>-rw-r--r-- 1 user user 1.3K Nov 1 10:00 ca.crt
-rw------- 1 user user 1.7K Nov 1 10:00 ca.key
-rw-r--r-- 1 user user 17 Nov 1 10:00 ca.srl
-rw-r--r-- 1 user user 1.1K Nov 1 10:00 blue.crt
-rw-r--r-- 1 user user 920 Nov 1 10:00 blue.csr
-rw------- 1 user user 1.7K Nov 1 10:00 blue.key</pre>
Files explained:

* '''ca.crt''': CA certificate (public, distribute to clients)
* '''ca.key''': CA private key (KEEP SECRET)
* '''ca.srl''': Serial number tracker (internal bookkeeping)
* '''blue.crt''': Blue's signed certificate (public)
* '''blue.csr''': Certificate signing request (can be deleted after signing)
* '''blue.key''': Blue's private key (KEEP SECRET)


==== Understanding the Trust Model ====

In our lab:

* Clients trust ca.crt (we'll explicitly provide it)
* blue.crt is signed by ca.crt
* Therefore, clients trust blue.crt

In the real world:

* Your browser/OS ships with ~150 pre-trusted root CAs
* When you visit https://example.com, the server sends its certificate
* Browser verifies the certificate chain: example.com cert → Intermediate CA → Root CA (in trust store)
* If chain is valid and domain name matches, connection is trusted

This is why certificate authorities are critical infrastructure. Compromise of a CA's private key would allow attackers to create trusted certificates for any domain.


==== Deliverable C: Provide the following: ====

# '''File Listing''': Output of <code>ls -lh pki</code> showing all six files with their sizes.
# '''Certificate Inspection''': Output of <code>openssl x509 -in blue.crt -text -noout</code> showing the certificate details. Circle or highlight:
#* The Issuer (should be root-ca)
#* The Subject (should be blue.lab)
#* The Validity dates
# '''Explanation''': Write 3-4 sentences explaining:
#* What a Certificate Authority does
#* Why we need both a private key (blue.key) and a certificate (blue.crt)
#* What the signature in the certificate proves


=== Exercise D: Secured Transport with TLS Encryption ===


==== Theory: Encryption in Action ====

Now we put everything together: TCP for reliable transport + TLS for encryption using our PKI.

When Red connects to Blue with TLS:

# '''TCP Handshake''': Establish connection (SYN, SYN-ACK, ACK)
# '''TLS Handshake''':
#* Negotiate cipher suite and TLS version
#* Blue sends its certificate (blue.crt)
#* Red verifies the certificate is signed by ca.crt (which we'll provide)
#* Exchange keys using public key cryptography
#* Derive shared symmetric encryption keys
# '''Encrypted Data Transfer''': All application data encrypted with the shared keys

After the handshake, all data is encrypted with fast symmetric encryption (typically AES), but the keys were securely exchanged using asymmetric encryption.

We'll use <code>tcpdump</code> to show that eavesdroppers (our host acting as "man in the middle") can't read the encrypted traffic.


==== Practice: TLS-Secured Connection ====

'''Step 1: Start the Secure Server'''

In Terminal 1, start ncat in SSL/TLS mode in Blue:

<syntaxhighlight lang="bash">sudo ip netns exec blue ncat --ssl --ssl-cert pki/blue.crt --ssl-key pki/blue.key -l -p 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-cert pki/blue.crt</code>: Server certificate
* <code>--ssl-key pki/blue.key</code>: Server private key
* <code>-l -p 8443</code>: Listen on port 8443 (can choose any port)

The server is now ready to accept TLS connections.

'''Step 2: Start the Wiretapper'''

In Terminal 2 on the host, capture traffic on port 8443:

<syntaxhighlight lang="bash">sudo tcpdump -i br-lab -X -s 0 port 8443</syntaxhighlight>
Command breakdown:

* <code>-X</code>: Show hex/ASCII payload
* <code>-s 0</code>: Capture full packets (no truncation)
* <code>port 8443</code>: Match source or destination port 8443

This is our "attacker" position, intercepting traffic between Red and Blue.

'''Step 3: Start the Secure Client'''

In Terminal 3, connect from Red with TLS enabled:

<syntaxhighlight lang="bash">sudo ip netns exec red ncat --ssl --ssl-verify --ssl-trustfile pki/ca.crt 10.0.0.3 8443</syntaxhighlight>
Command breakdown:

* <code>--ssl</code>: Enable SSL/TLS
* <code>--ssl-verify</code>: Verify server certificate (don't accept self-signed or invalid certificates)
* <code>--ssl-trustfile pki/ca.crt</code>: Trust anchor (our CA certificate)
* <code>10.0.0.3 8443</code>: Connect to Blue on port 8443

You should see the connection succeed. If you see an error like "certificate verification failed," check:

* blue.crt Common Name matches the IP/hostname you're connecting to (we used blue.lab in the cert but are connecting to 10.0.0.3—this mismatch is OK for this lab since we're using <code>--ssl-trustfile</code>)
* ca.crt is the correct CA certificate
* blue.crt is signed by ca.crt

'''Step 4: Observe the TLS Handshake'''

In Terminal 2 (tcpdump), you should see several packets immediately after connection. These are the TLS handshake:

<pre>16:30:45.123456 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 1:517, ack 1, length 516
0x0000: 4500 0234 1234 4000 4006 abcd 0a00 0002 E..4.4@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5678 1234 5678 .....n...4Vx.4Vx
0x0020: 5018 ffff abcd 0000 1603 0301 ff01 0001 P...............
0x0030: fb03 0356 4e12 3456 789a bcde f012 3456 ...VN.4Vx.....4V
0x0040: 789a bcde f012 3456 789a bcde f012 3456 x...4Vx.....4V
...</pre>
Notice:

* The payload starts with <code>0x16 0x03 0x03</code> (TLS Handshake, TLS 1.2)
* The data looks random (it contains encrypted pre-master secrets, cipher suites, etc.)
* You can't read any meaningful content

'''Step 5: Send a Secret Message'''

In Terminal 3 (Red client), type:

<pre>This is a Secret Password: MyP@ssw0rd123</pre>
Press Enter.

The message should appear in Terminal 1 (Blue server) in plaintext—the TLS layer decrypts it automatically before delivering to the application.

'''Step 6: Inspect the Encrypted Traffic'''

Look at Terminal 2 (tcpdump). You should see packets containing the encrypted message:

<pre>16:31:02.234567 IP 10.0.0.2.45678 > 10.0.0.3.8443: Flags [P.], seq 517:572, length 55
0x0000: 4500 005f 1235 4000 4006 abc2 0a00 0002 E.._.5@.@.......
0x0010: 0a00 0003 b26e 20fb 1234 5890 1234 5890 .....n...4X..4X.
0x0020: 5018 ffff abcd 0000 1703 0300 32a4 f7b3 P.........2.....
0x0030: 8c44 e291 bc73 4fa8 d612 e8f3 9a45 b7c9 .D...sO......E..
0x0040: 1f22 d847 b3a5 c7e9 2d48 f6a4 b812 d7c4 .".G....-H......
0x0050: 3a95 e8f6 b2d1 c847 a5e3 9f :......G...</pre>
Critical observation: '''Can you read "This is a Secret Password" in the hex dump?'''

No! You see random-looking bytes. The actual payload is:

* Encrypted with AES or ChaCha20 (symmetric encryption)
* Authenticated with HMAC or AEAD
* Completely unreadable without the encryption keys

Compare this to Exercise A (UDP) where you could clearly read "Hello UDP World" in the packet capture.

'''Step 7: Send More Data'''

Try sending additional messages:

<pre>Credit Card: 4532-1234-5678-9012
SSN: 123-45-6789
API Key: sk_live_1234567890abcdefghijklmnopqrstuvwxyz</pre>
Each appears in plaintext on the server (Terminal 1) but as encrypted gibberish in the packet capture (Terminal 2).

This is exactly how HTTPS protects your sensitive data when you browse websites. Between your browser and the web server, your data is encrypted. Even if someone intercepts the packets (your ISP, a coffee shop WiFi operator, a government agency), they see only encrypted data.

'''Step 8: Cleanup'''

Press Ctrl+C in all terminals to stop the processes.


==== Understanding What Happened ====

The TLS handshake (simplified):

# Red sends "ClientHello" with supported cipher suites
# Blue sends "ServerHello" with chosen cipher suite + blue.crt certificate
# Red verifies blue.crt is signed by ca.crt (from <code>--ssl-trustfile</code>)
# Red verifies certificate CN, validity dates, etc.
# Red generates a pre-master secret, encrypts it with Blue's public key (from blue.crt), sends it
# Both sides derive the same symmetric encryption keys from the pre-master secret
# Both sides send "Finished" messages encrypted with the new keys
# All subsequent data is encrypted with the symmetric keys

The symmetric keys are never transmitted—both sides independently compute them from the shared pre-master secret.


==== Real-World Context ====

This is how HTTPS works:

* Your browser has ~150 trusted root CAs built in
* You visit https://example.com
* Server sends its certificate, signed by a trusted CA
* Browser verifies the chain: example.com cert → Intermediate CA → Root CA
* If valid, browser shows padlock icon
* All data encrypted with TLS

Without TLS, someone could:

* Read your passwords
* Steal your session cookies
* Intercept your credit card numbers
* Modify downloads to inject malware

This is why the web has largely moved to HTTPS-by-default.


==== Deliverable D: Provide the following: ====

# '''tcpdump Output''': Screenshot or text of the packet capture showing encrypted data. The output must clearly show:
#* Source and destination (Red to Blue on port 8443)
#* The hex dump of the payload
#* The payload looks like random bytes (NOT readable text)
# '''Comparison''': Side-by-side comparison (can be text description or screenshot):
#* Exercise A UDP packet capture (plaintext visible)
#* Exercise D TLS packet capture (encrypted)
# '''Explanation''': Write 4-5 sentences explaining:
#* Why the tcpdump output shows gibberish instead of your actual message
#* What role the certificate (blue.crt) plays in establishing trust
#* How TLS prevents a man-in-the-middle attacker from reading your data


== Reference: Command Quick Guide ==

This section provides a quick reference for commands introduced in this lab.


=== Network Communication Tools ===

<syntaxhighlight lang="bash"># UDP Server
ncat -u -l -p <port>

# UDP Client
ncat -u <ip> <port>

# TCP Server
ncat -l -p <port>

# TCP Client
ncat <ip> <port>

# TCP Server with TLS
ncat --ssl --ssl-cert <cert> --ssl-key <key> -l -p <port>

# TCP Client with TLS (verify certificate)
ncat --ssl --ssl-verify --ssl-trustfile <ca_cert> <ip> <port>

# TCP Client with TLS (no verification - insecure)
ncat --ssl <ip> <port></syntaxhighlight>

=== Socket Inspection ===

<syntaxhighlight lang="bash"># Show all TCP sockets
ss -ta

# Show all TCP sockets, numeric, all states
ss -tna

# Show listening TCP sockets
ss -tln

# Show TCP sockets with process info (requires root)
ss -tnap

# Show UDP sockets
ss -una

# Show socket memory usage
ss -tm

# Show extended socket information
ss -tei

# Filter by state
ss -t state established
ss -t state time-wait

# Filter by port
ss -tn sport = :8080
ss -tn dport = :443</syntaxhighlight>

=== Port Scanning (nmap) ===

<syntaxhighlight lang="bash"># Scan specific port
nmap -p 22 <ip>

# Scan port range
nmap -p 1-1000 <ip>

# Scan all ports (slow)
nmap -p- <ip>

# Scan common ports (faster)
nmap --top-ports 100 <ip>

# TCP SYN scan (stealthy, requires root)
sudo nmap -sS <ip>

# TCP Connect scan (no root required)
nmap -sT <ip>

# UDP scan (slow)
sudo nmap -sU <ip>

# Service version detection
nmap -sV <ip>

# OS detection
sudo nmap -O <ip>

# Aggressive scan (OS, version, scripts)
sudo nmap -A <ip>

# Scan subnet
nmap 10.0.0.0/24

# Fast scan (no DNS resolution, no ping)
nmap -n -Pn <ip></syntaxhighlight>

=== Packet Capture (tcpdump) ===

<syntaxhighlight lang="bash"># Capture on interface
sudo tcpdump -i <interface>

# Show hex and ASCII
sudo tcpdump -i <interface> -X

# Capture specific port
sudo tcpdump -i <interface> port 8080

# Capture specific protocol
sudo tcpdump -i <interface> tcp
sudo tcpdump -i <interface> udp

# Capture TCP SYN packets
sudo tcpdump -i <interface> "tcp[tcpflags] & tcp-syn != 0"

# Capture TCP handshakes (SYN, FIN, RST)
sudo tcpdump -i <interface> "tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0"

# Save to file
sudo tcpdump -i <interface> -w capture.pcap

# Read from file
tcpdump -r capture.pcap

# Capture full packets (no truncation)
sudo tcpdump -i <interface> -s 0

# Show absolute sequence numbers
sudo tcpdump -i <interface> -S

# Don't resolve hostnames (faster)
sudo tcpdump -i <interface> -n

# Capture only N packets
sudo tcpdump -i <interface> -c 10</syntaxhighlight>

=== Certificate Management (openssl) ===

<syntaxhighlight lang="bash"># Generate self-signed CA
openssl req -new -x509 -days 365 -nodes \
-subj "/C=XX/ST=State/L=City/O=Org/CN=CA" \
-keyout ca.key -out ca.crt

# Generate private key
openssl genrsa -out server.key 2048
openssl genrsa -out server.key 4096 # More secure

# Generate CSR
openssl req -new -key server.key \
-subj "/C=XX/ST=State/L=City/O=Org/CN=domain.com" \
-out server.csr

# Sign CSR with CA
openssl x509 -req -in server.csr \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-out server.crt -days 365

# View certificate (human-readable)
openssl x509 -in cert.crt -text -noout

# View CSR
openssl req -in cert.csr -text -noout

# View private key
openssl rsa -in key.key -text -noout

# Extract specific fields
openssl x509 -in cert.crt -noout -subject
openssl x509 -in cert.crt -noout -issuer
openssl x509 -in cert.crt -noout -dates
openssl x509 -in cert.crt -noout -serial
openssl x509 -in cert.crt -noout -fingerprint

# Verify certificate chain
openssl verify -CAfile ca.crt cert.crt

# Check certificate and key match
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in key.key | openssl md5
# If MD5 hashes match, certificate and key are paired

# Convert formats
openssl x509 -in cert.pem -out cert.der -outform DER # PEM to DER
openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM # DER to PEM

# Test TLS connection
openssl s_client -connect domain.com:443 -CAfile ca.crt</syntaxhighlight>

=== Common Port Numbers Reference ===

{| class="wikitable"
|-
! Port
! Service
! Protocol
! Description
|-
| 20
| FTP-DATA
| TCP
| FTP data transfer
|-
| 21
| FTP
| TCP
| FTP control
|-
| 22
| SSH
| TCP
| Secure Shell
|-
| 23
| Telnet
| TCP
| Unencrypted remote access
|-
| 25
| SMTP
| TCP
| Email sending
|-
| 53
| DNS
| UDP/TCP
| Domain Name System
|-
| 67/68
| DHCP
| UDP
| Dynamic IP configuration
|-
| 80
| HTTP
| TCP
| Web traffic (unencrypted)
|-
| 110
| POP3
| TCP
| Email retrieval
|-
| 143
| IMAP
| TCP
| Email retrieval
|-
| 443
| HTTPS
| TCP
| Web traffic (encrypted)
|-
| 465
| SMTPS
| TCP
| SMTP over TLS
|-
| 587
| SMTP
| TCP
| SMTP (submission)
|-
| 993
| IMAPS
| TCP
| IMAP over TLS
|-
| 995
| POP3S
| TCP
| POP3 over TLS
|-
| 3306
| MySQL
| TCP
| MySQL database
|-
| 3389
| RDP
| TCP
| Remote Desktop Protocol
|-
| 5432
| PostgreSQL
| TCP
| PostgreSQL database
|-
| 6379
| Redis
| TCP
| Redis cache
|-
| 8080
| HTTP-Alt
| TCP
| Alternative HTTP port
|-
| 8443
| HTTPS-Alt
| TCP
| Alternative HTTPS port
|}


=== TCP State Reference ===

{| class="wikitable"
|-
! State
! Description
! Typical Duration
|-
| CLOSED
| No connection
| N/A
|-
| LISTEN
| Server waiting for connections
| Indefinite
|-
| SYN_SENT
| Client sent SYN, waiting for SYN-ACK
| Milliseconds
|-
| SYN_RCVD
| Server received SYN, sent SYN-ACK
| Milliseconds
|-
| ESTABLISHED
| Connection active, data transfer
| Seconds to hours
|-
| FIN_WAIT_1
| Active close, sent FIN
| Milliseconds
|-
| FIN_WAIT_2
| Active close, received ACK for FIN
| Seconds
|-
| CLOSE_WAIT
| Passive close, received FIN
| Variable (app-dependent)
|-
| CLOSING
| Both sides closing simultaneously
| Milliseconds
|-
| LAST_ACK
| Passive close, sent FIN
| Milliseconds
|-
| TIME_WAIT
| Final state after close
| 60-240 seconds
|}


=== Cipher Suite Examples ===

Modern cipher suites (TLS 1.3):

* <code>TLS_AES_256_GCM_SHA384</code>
* <code>TLS_CHACHA20_POLY1305_SHA256</code>
* <code>TLS_AES_128_GCM_SHA256</code>

Legacy cipher suites (TLS 1.2):

* <code>ECDHE-RSA-AES256-GCM-SHA384</code>
* <code>ECDHE-RSA-AES128-GCM-SHA256</code>
* <code>DHE-RSA-AES256-GCM-SHA384</code>

Cipher suite components:

* Key exchange: ECDHE, DHE, RSA
* Authentication: RSA, ECDSA, Ed25519
* Encryption: AES-256-GCM, AES-128-GCM, ChaCha20-Poly1305
* Hash: SHA256, SHA384


== Deliverables and Assessment ==

Submit a single PDF document containing all Exercise Deliverables (A-D).


== Additional Resources ==

This lab introduced the transport layer (UDP, TCP) and applied cryptography (PKI, TLS) to secure communications. These concepts are foundational to understanding modern networked systems and security.


=== For Further Study: ===

'''Transport Protocols:'''

* TCP congestion control algorithms (Reno, Cubic, BBR)
* TCP fast open (TFO) for reduced latency
* QUIC/HTTP/3 for modern applications
* SCTP (Stream Control Transmission Protocol)
* Multipath TCP (MPTCP) for using multiple interfaces simultaneously

'''Security and Cryptography:'''

* TLS 1.3 improvements over TLS 1.2
* Certificate pinning for enhanced security
* Elliptic curve cryptography (ECDSA, Ed25519)
* Perfect forward secrecy (PFS)
* HSTS (HTTP Strict Transport Security)
* Certificate Transparency logs

'''Network Monitoring and Debugging:'''

* Wireshark for advanced packet analysis
* tshark for command-line packet analysis
* iptraf-ng for real-time network monitoring
* netstat and ss advanced features
* strace for tracing system calls related to networking

'''Secure Communication Tools:'''

* WireGuard VPN
* OpenVPN
* SSH tunneling and port forwarding
* mTLS (mutual TLS) for client authentication
* SOCKS proxies

'''Network Security:'''

* Firewall configuration (nftables, iptables)
* IDS/IPS systems (Snort, Suricata)
* Network segmentation and VLANs
* DDoS mitigation techniques
* Zero-trust networking

'''Performance Optimization:'''

* TCP tuning (window size, buffer sizes)
* Nagle's algorithm and TCP_NODELAY
* TCP keepalive configuration
* Connection pooling
* Load balancing techniques


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 7 tcp # TCP protocol overview
man 7 udp # UDP protocol overview
man 7 ip # IP protocol overview
man 8 ss # Socket statistics utility
man 8 nmap # Network exploration tool
man 8 tcpdump # Packet capture tool
man 1 openssl # OpenSSL command-line tool
man 1 ncat # Ncat (netcat) tool
man 5 nftables # nftables firewall</syntaxhighlight>

=== Online Resources: ===

* [https://en.wikipedia.org/wiki/TCP/IP_Illustrated TCP/IP Illustrated by W. Richard Stevens] - Classic networking book
* [https://hpbn.co/ High Performance Browser Networking] - Free online book by Ilya Grigorik
* [https://www.rfc-editor.org/rfc/rfc8446 TLS 1.3 RFC 8446]
* [https://www.rfc-editor.org/rfc/rfc9000 QUIC RFC 9000]
* [https://letsencrypt.org/docs/ Let's Encrypt Documentation] - Free CA for real certificates
* [https://www.ssllabs.com/ SSL Labs] - Test TLS configuration of real websites
* [https://www.wireshark.org/docs/ Wireshark Documentation]
* [https://nmap.org/docs.html Nmap Documentation]

Operating Systems

2025-11-28T13:22:54Z

Vserbu:

OS Lab 7 - The Network Subsystem

2025-11-21T15:02:02Z

Vserbu:

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how the kernel represents network abstractions: Interfaces, Addresses, Routes, and Neighbors.
* Use the modern iproute2 suite (<code>ip link</code>, <code>ip addr</code>, <code>ip route</code>, <code>ip neigh</code>) to manage kernel network objects.
* Create isolated network environments using Network Namespaces to simulate multiple virtual computers.
* Construct a complete virtual network topology (Switch, Router, NAT) from scratch using OS primitives.
* Diagnose connectivity issues by inspecting the ARP cache and Routing table to understand packet delivery.
* Understand the relationship between Layer 2 (MAC addresses) and Layer 3 (IP addresses) networking.


== Introduction ==

In Lab 6, we explored Inter-Process Communication (IPC) mechanisms that allow processes to exchange data and coordinate their actions. We touched briefly on Sockets, which extend IPC beyond a single machine by enabling communication across network boundaries. However, using sockets effectively requires understanding what happens beneath the abstraction: how does data actually travel from one machine to another?

The answer lies in the kernel's network stack, a complex subsystem responsible for managing network interfaces, addressing, routing, and protocol handling. Usually, the network stack is configured automatically by background services like NetworkManager, systemd-networkd, or DHCP clients. These tools shield users from complexity, but they also obscure the fundamental mechanisms at work.

In this lab, we peel back those layers to interact directly with the kernel's networking subsystem. We will not use physical network cables or hardware switches. Instead, we will use the operating system itself to manufacture virtual hardware—virtual network cards, virtual cables, and virtual switches. By constructing networks programmatically, we gain deep insight into how the kernel manages connectivity, routing, and address resolution.

This lab is structured around a progression: we start with a simple point-to-point connection between two virtual machines, then evolve it into a switched network with multiple clients, routing capabilities, and internet access via Network Address Translation (NAT). Along the way, we examine the kernel's internal state at each step to understand exactly how packets flow through the system.

Understanding the network subsystem is essential for system administration, DevOps, container orchestration (Docker, Kubernetes), network troubleshooting, and security. These same primitives underlie modern cloud networking, virtual private networks, and service meshes.


== Prerequisites ==


=== System Requirements ===

A running instance of Linux machine with root privileges (via <code>sudo</code>).


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y iproute2 iputils-ping traceroute nftables</syntaxhighlight>
* <code>iproute2</code>: The modern suite for network configuration, replacing legacy tools like <code>ifconfig</code> and <code>route</code>. Provides <code>ip</code> command.
* <code>iputils-ping</code>: Provides the <code>ping</code> utility for testing connectivity.
* <code>traceroute</code>: Maps the path packets take through networks.
* <code>nftables</code>: The modern Linux firewall/NAT framework.


== Knowledge Prerequisites ==

You should be familiar with:

* Process concepts from Lab 3 (PIDs, process hierarchy)
* File permissions from Lab 4 (execute bit, ownership)
* Bash scripting from Lab 5 (shebangs, variables, loops, functions)
* IPC concepts from Lab 6 (understanding of how processes communicate)


== The Network Subsystem: Kernel Fundamentals ==


==== What is a Network? ====

To the Linux kernel, a "Network" is not a physical thing—it's an abstraction representing a group of computers that can communicate with each other directly, without requiring a router as an intermediary. This direct communication capability is what defines a network segment or broadcast domain.

A single computer can participate in multiple networks simultaneously. It simply needs a separate Network Interface for each network it wants to join. Think of interfaces as "plugs" or "sockets" that connect your computer to different communication channels.


==== The Four Pillars of Networking ====

The kernel's network subsystem is built on four fundamental abstractions. Understanding these is key to mastering network configuration:

# '''Interfaces''': The physical or virtual network adapters that can send and receive packets. Each interface represents a connection point to a network.
# '''Addresses''': IP addresses assigned to interfaces, giving them identities on the network. Addresses define "who" you are.
# '''Routes''': Kernel rules that determine which interface should be used to reach a given destination. Routes define "how to get there."
# '''Neighbors''': The kernel's cache mapping IP addresses to MAC addresses for direct communication. Neighbors define "where exactly on this wire."

These four abstractions work together. When you send a packet to an IP address:

# The kernel consults the '''Routing Table''' to determine which '''Interface''' to use.
# If the route indicates the destination is local (directly reachable), the kernel consults the '''Neighbor Table''' to find the MAC address.
# If the MAC address is unknown, the kernel uses ARP (Address Resolution Protocol) to discover it.
# The kernel constructs an Ethernet frame with the destination MAC address and sends it out the chosen '''Interface'''.


==== The iproute2 Suite: Modern Network Management ====

Historically, Linux used separate commands for each aspect of networking: <code>ifconfig</code> for interfaces, <code>route</code> for routing, <code>arp</code> for neighbors. These tools are now considered legacy. Modern Linux uses the unified <code>iproute2</code> suite, centered around the <code>ip</code> command.

The <code>ip</code> command uses a consistent syntax:

<syntaxhighlight lang="bash">ip OBJECT COMMAND [OPTIONS]</syntaxhighlight>
Where OBJECT is one of:

* <code>link</code>: Network interfaces (Layer 2)
* <code>addr</code> or <code>address</code>: IP addresses (Layer 3)
* <code>route</code>: Routing table entries
* <code>neigh</code> or <code>neighbour</code>: ARP/Neighbor cache

Common commands:

* <code>ip link show</code>: List all network interfaces
* <code>ip addr show</code>: Show IP addresses assigned to interfaces
* <code>ip route show</code>: Display the routing table
* <code>ip neigh show</code>: Display the neighbor (ARP) cache

The beauty of <code>ip</code> is that it provides a consistent, scriptable interface to the kernel's network state. Unlike older tools, <code>ip</code> is designed for automation and parsing by scripts.


==== Network Namespaces: Virtual Computers ====

A Network Namespace (often abbreviated "netns") is a kernel feature that creates an isolated copy of the network stack. Each namespace has its own:

* Set of network interfaces
* Routing table
* ARP cache
* Firewall rules
* Socket listening ports

From the kernel's perspective, a network namespace is effectively a separate "Virtual Computer" with its own completely independent networking configuration. Processes running inside a namespace cannot see or interact with interfaces or connections in other namespaces (unless explicitly bridged).

Your Linux host runs in the "default" or "root" namespace. When you run <code>ip link show</code> normally, you see the default namespace's interfaces. But we can create new namespaces to simulate remote machines for testing, all on a single physical computer.

Network namespaces are the foundation of container networking. When you run a Docker container, Docker creates a new network namespace for it, giving the container its own isolated network stack.

Commands for working with namespaces:

* <code>ip netns add NAME</code>: Create a new namespace
* <code>ip netns list</code>: List all namespaces
* <code>ip netns exec NAME COMMAND</code>: Execute a command inside a namespace
* <code>ip netns delete NAME</code>: Remove a namespace

When you execute a command with <code>ip netns exec client_ns ip link</code>, you're running the <code>ip link</code> command inside the <code>client_ns</code> namespace, so it sees only that namespace's interfaces.


== Hands-on Exercises ==

In this lab, we will start by building a simple direct connection between two virtual computers, then evolve it step-by-step into a complex switched network with routing and NAT.


=== Exercise 1: Network Interfaces and Virtual Cables ===


==== Theory: The Virtual Ethernet (veth) Pair ====

Physical networks require network interface cards (NICs) and physical cables. Virtual networks require virtual equivalents. The Linux kernel provides several types of virtual interfaces:

* '''veth (Virtual Ethernet) pairs''': A veth pair is like a virtual patch cable with two ends. Packets sent into one end immediately come out the other end. veth pairs are the fundamental building block for connecting network namespaces.
* '''bridges''': Virtual switches that connect multiple interfaces together.
* '''tun/tap devices''': Virtual interfaces used by userspace programs (like VPNs).
* '''vlan devices''': Virtual interfaces representing 802.1Q VLAN tags.

In this exercise, we focus on veth pairs. When you create a veth pair, the kernel creates two interfaces that are permanently wired together. You can place these interfaces in different namespaces, effectively running a "cable" between two virtual machines.

Every network interface, physical or virtual, has several properties:

* '''Name''': The interface identifier (e.g., <code>eth0</code>, <code>v-host</code>)
* '''MAC Address''': A Layer 2 hardware address (48 bits, typically written as six hex pairs like <code>aa:bb:cc:dd:ee:ff</code>)
* '''State''': UP (enabled) or DOWN (disabled)
* '''MTU''': Maximum Transmission Unit, the largest packet size the interface can handle

Even virtual interfaces have MAC addresses. The kernel auto-generates them, though you can set them manually if needed.


==== Practice: Creating Your First Virtual Network ====

We will create two virtual computers: your host (running in the default namespace) and a client (running in a new namespace called <code>client_ns</code>). We'll connect them with a veth pair.


===== Step 1: Examine Your Current Network Configuration =====

Before we begin constructing virtual networks, let's see what we're starting with:

<syntaxhighlight lang="bash">ip link show</syntaxhighlight>
You should see at least two interfaces:

* <code>lo</code>: The loopback interface (127.0.0.1), used for local communication within the machine
* <code>eth0</code> (or <code>ens33</code>, <code>enp0s3</code>, etc.): Your primary physical (or virtualized) network interface connected to the outside world

Note the MAC addresses, the state (UP or DOWN), and the MTU (typically 1500 bytes for Ethernet).

Each interface has an "ifindex" number, which is the kernel's internal identifier. You'll see output like:

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff</pre>
The flags like <code><BROADCAST,MULTICAST,UP,LOWER_UP></code> indicate interface capabilities and state. <code>UP</code> means the interface is enabled, <code>LOWER_UP</code> means the link layer is connected.


===== Step 2: Create a Virtual Ethernet Cable =====

Create a veth pair. This is like manufacturing a network cable with two connectors:

<syntaxhighlight lang="bash">sudo ip link add dev v-host type veth peer name v-client</syntaxhighlight>
Let's break down this command:

* <code>ip link add</code>: Create a new interface
* <code>dev v-host</code>: Name one end "v-host"
* <code>type veth</code>: The interface type is a virtual ethernet pair
* <code>peer name v-client</code>: Name the other end "v-client"

Verify the creation:

<syntaxhighlight lang="bash">ip link show</syntaxhighlight>
You should now see two additional interfaces: <code>v-host</code> and <code>v-client</code>. Both will be in state <code>DOWN</code> initially. Notice that each has been automatically assigned a MAC address by the kernel. These MAC addresses are randomly generated to avoid collisions.

Important: The two interfaces are linked. Packets sent to <code>v-host</code> will appear on <code>v-client</code>, and vice versa. This is how we'll connect our host to the virtual client machine.


===== Step 3: Create a Virtual Computer (Network Namespace) =====

Create a new network namespace to simulate a separate computer:

<syntaxhighlight lang="bash">sudo ip netns add client_ns</syntaxhighlight>
Verify it exists:

<syntaxhighlight lang="bash">ip netns list</syntaxhighlight>
You should see <code>client_ns</code> in the output.

This namespace is now a completely isolated network environment. It has its own set of interfaces (initially just a loopback), its own routing table, and its own ARP cache.

Let's peek inside to see what interfaces exist in the new namespace:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link show</syntaxhighlight>
You should see only the loopback interface (<code>lo</code>). The <code>v-client</code> interface we created is still in the default namespace.


===== Step 4: Connect the Virtual Cable =====

Now we'll "plug" one end of our virtual cable into the virtual computer. We do this by moving the <code>v-client</code> interface from the default namespace into <code>client_ns</code>:

<syntaxhighlight lang="bash">sudo ip link set v-client netns client_ns</syntaxhighlight>
This command transfers ownership of the <code>v-client</code> interface to the <code>client_ns</code> namespace.


===== Step 5: Verify the Topology =====

Verify the change in the default namespace:

<syntaxhighlight lang="bash">ip link show</syntaxhighlight>
Notice that <code>v-client</code> is now '''gone''' from the default namespace. It has moved to <code>client_ns</code>.

Verify inside the namespace:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link show</syntaxhighlight>
Now you should see both <code>lo</code> and <code>v-client</code> inside the namespace.

At this point, we have successfully created a virtual topology:

* '''Host''' (default namespace): Has interface <code>v-host</code>
* '''Client''' (client_ns namespace): Has interface <code>v-client</code>
* '''Connection''': <code>v-host</code> and <code>v-client</code> are connected by a virtual cable

However, neither interface is UP yet, and neither has an IP address. They cannot communicate yet.


==== Deliverable A ====

After following exercise 1, provide the output of the following commands:

<syntaxhighlight lang="bash">ip link show | grep v-host
sudo ip netns exec client_ns ip link show | grep v-client</syntaxhighlight>

=== Exercise 2: IP Addresses and Subnets ===


==== Theory: Identity and Reachability ====

Network interfaces allow computers to physically connect to a network, but to actually communicate, they need identities—IP addresses. An IP address serves two purposes:

# '''Identity''': It uniquely identifies a device on a network (like a phone number)
# '''Routing''': It indicates which network the device belongs to (like an area code)

An IP address by itself is not enough. We also need a subnet mask (or prefix length) that defines the "scope" of the local network—which other IP addresses are directly reachable without routing.


===== Understanding Subnet Masks and CIDR Notation =====

A subnet mask divides an IP address into two parts:

* '''Network portion''': Identifies which network the address belongs to
* '''Host portion''': Identifies the specific device within that network

CIDR (Classless Inter-Domain Routing) notation uses a slash followed by the number of bits in the network portion. For example:

* <code>10.0.0.5/24</code>: The first 24 bits (10.0.0) are the network, leaving 8 bits for hosts (256 addresses: 10.0.0.0 - 10.0.0.255)
* <code>192.168.1.10/16</code>: The first 16 bits (192.168) are the network, leaving 16 bits for hosts (65,536 addresses)
* <code>172.16.0.1/8</code>: The first 8 bits (172) are the network, leaving 24 bits for hosts (16,777,216 addresses)

When you assign an IP address with a prefix length (e.g., <code>10.0.0.1/24</code>), the kernel automatically understands that all addresses matching the network portion (10.0.0.x) are "local" or "directly reachable."


===== The Subnet Decision: How the Kernel Routes Locally =====

When a process wants to send a packet to a destination IP address, the kernel must decide: "Is this destination a neighbor on one of my local networks, or do I need to forward it to a router?"

The kernel's logic:

# For each interface with an assigned IP address and subnet mask, calculate the network address
# Check if the destination IP falls within any of these networks
# If yes → the destination is directly reachable; send the packet out that interface using the destination's MAC address
# If no → consult the routing table for a gateway to forward the packet through

Example: Your interface has IP <code>10.0.0.1/24</code>

* Network: <code>10.0.0.0/24</code> (all addresses from 10.0.0.0 to 10.0.0.255)
* If you ping <code>10.0.0.50</code>: The kernel recognizes this is in the local subnet and sends directly
* If you ping <code>8.8.8.8</code>: The kernel recognizes this is NOT local and looks for a route to a gateway

This automatic local route is created when you assign an IP address. You don't need to manually configure routes for local subnets.


===== Static vs. Dynamic Configuration =====

IP addresses can be configured in two ways:

* '''Static''': Manually assigned by an administrator using <code>ip addr add</code>
* '''Dynamic''': Automatically assigned by a DHCP server

In production systems, DHCP is common because it allows centralized management of address allocation. In this lab, we use static configuration to understand exactly what the kernel is doing.


==== Practice: Assigning IP Addresses ====

We will assign IP addresses to both ends of our virtual cable, placing them in the same subnet so they can communicate directly.


===== Step 1: Understand the Current State =====

Check if any IP addresses are assigned to <code>v-host</code>:

<syntaxhighlight lang="bash">ip addr show v-host</syntaxhighlight>
You should see only the MAC address, no IP addresses. The interface is also DOWN (note <code>state DOWN</code>).

Similarly, check the client:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip addr show v-client</syntaxhighlight>
Same situation: no IP address, interface DOWN.


===== Step 2: Assign IP Address to the Client =====

We'll assign <code>10.0.0.2/24</code> to the client's interface. The <code>/24</code> means the first 24 bits are the network portion, so this device considers all addresses from <code>10.0.0.0</code> to <code>10.0.0.255</code> as local neighbors.

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip addr add 10.0.0.2/24 dev v-client</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip addr show v-client</syntaxhighlight>
You should see:

<pre>inet 10.0.0.2/24 scope global v-client</pre>

===== Step 3: Bring the Client Interface UP =====

Interfaces are created in the DOWN state by default. We must explicitly enable them:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link set v-client up</syntaxhighlight>
Also bring up the loopback interface (required for many network operations):

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link set lo up</syntaxhighlight>
Verify the state changed to UP:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link show v-client</syntaxhighlight>
Look for <code>state UP</code> in the output.


===== Step 4: Assign IP Address to the Host =====

Now configure the host end of the cable with <code>10.0.0.1/24</code> (same subnet):

<syntaxhighlight lang="bash">sudo ip addr add 10.0.0.1/24 dev v-host</syntaxhighlight>
Bring it up:

<syntaxhighlight lang="bash">sudo ip link set v-host up</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">ip addr show v-host</syntaxhighlight>

===== Step 5: Verify Connectivity =====

The moment of truth. Can the host reach the client?

<syntaxhighlight lang="bash">ping -c 3 10.0.0.2</syntaxhighlight>
If successful, you'll see output like:

<pre>PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.040 ms</pre>
Congratulations! You've established your first virtual network connection. The host and client can now communicate.

Can the client ping the host?

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 3 10.0.0.1</syntaxhighlight>
This should also succeed. Communication is bidirectional.

Why Does This Work?

Let's trace what happens when you <code>ping 10.0.0.2</code> from the host:

# '''Destination Analysis''': The kernel looks at the destination IP <code>10.0.0.2</code> and your interface <code>v-host</code> with IP <code>10.0.0.1/24</code>. It calculates: "10.0.0.2 is in the 10.0.0.0/24 network, which matches my v-host subnet. This is a local destination."
# '''MAC Address Resolution''': The kernel needs the MAC address of 10.0.0.2. It doesn't know it yet, so it broadcasts an ARP request on <code>v-host</code>: "Who has 10.0.0.2? Please tell 10.0.0.1."
# '''ARP Reply''': The client (in client_ns) receives the ARP request on <code>v-client</code>, recognizes its own IP, and replies: "10.0.0.2 is at MAC address aa:bb:cc:dd:ee:ff" (the MAC of v-client).
# '''Packet Transmission''': Now the host knows the MAC address. It constructs an ICMP Echo Request packet, wraps it in an Ethernet frame addressed to the client's MAC, and sends it out <code>v-host</code>.
# '''Packet Reception''': The packet instantly appears on <code>v-client</code> (because they're a veth pair), travels up the network stack in client_ns, and the kernel processes the ICMP Echo Request.
# '''Reply''': The client sends an ICMP Echo Reply back to 10.0.0.1, using the same process in reverse.

All of this happens in milliseconds, managed entirely by the kernel.


==== Deliverable B ====

After following exercise 2, show the output of the following commands:

<syntaxhighlight lang="bash">ip addr show v-host
sudo ip netns exec client_ns ip addr show v-client
ping -c 3 10.0.0.2</syntaxhighlight>

=== Exercise 3: Neighbor Discovery and ARP ===

So far, we've worked with IP addresses , but the physical network uses MAC addresses. How does the kernel translate between them?


==== Thwory ====


===== The Address Resolution Protocol (ARP) =====

ARP is the protocol that maps IP addresses to MAC addresses on Ethernet networks. When the kernel needs to send a packet to an IP address that it knows is on a local network, it must first discover the target's MAC address.

The ARP process:

# The kernel checks its '''Neighbor Table''' (ARP cache) for an existing entry mapping the destination IP to a MAC address
# If found, use it
# If not found:
#* Broadcast an ARP Request packet on the local network: "Who has IP X.X.X.X? Tell Y.Y.Y.Y."
#* Wait for an ARP Reply: "IP X.X.X.X is at MAC aa:bb:cc:dd:ee:ff"
#* Cache this mapping in the Neighbor Table for future use

ARP is a broadcast protocol at Layer 2. Every device on the local network segment receives the ARP request, but only the device with the matching IP address responds.


===== The Neighbor Table =====

The kernel maintains a Neighbor Table (also called the ARP cache) mapping IP addresses to MAC addresses. Entries have states:

* '''REACHABLE''': The entry is valid and recently confirmed
* '''STALE''': The entry is old but assumed still valid
* '''DELAY''': Awaiting confirmation
* '''INCOMPLETE''': ARP request sent, waiting for reply
* '''FAILED''': ARP request failed, no reply received

Entries automatically expire after a timeout (typically a few minutes of inactivity) to handle cases where devices change MAC addresses or leave the network.

You can view the Neighbor Table with:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
Or the older command:

<syntaxhighlight lang="bash">arp -n</syntaxhighlight>

===== Why ARP Matters for Troubleshooting =====

Many network connectivity issues that seem like "routing problems" are actually ARP problems:

* The kernel can't deliver packets because it never receives an ARP reply
* Stale ARP entries point to the wrong MAC address after a device changes
* ARP conflicts occur when two devices claim the same IP address

Understanding ARP is essential for diagnosing these issues.


==== Practice: Inspecting the ARP Cache ====


===== Step 1: View Current Neighbors =====

Check your neighbor table:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
You should see an entry for <code>10.0.0.2</code> (the client) with its MAC address and state <code>REACHABLE</code>:

<pre>10.0.0.2 dev v-host lladdr aa:bb:cc:dd:ee:ff REACHABLE</pre>
This entry was created when you pinged the client in Exercise 2. The "lladdr" (link-layer address) is the MAC address.

Also check from the client's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip neigh show</syntaxhighlight>
You should see an entry for <code>10.0.0.1</code> (the host).


===== Step 2: Flush the ARP Cache =====

Let's simulate a situation where the kernel has forgotten the MAC address mappings:

<syntaxhighlight lang="bash">sudo ip neigh flush all</syntaxhighlight>
Verify they're gone:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
The entry for <code>10.0.0.2</code> should be absent or in state <code>FAILED</code> or <code>INCOMPLETE</code>.


===== Step 3: Watch ARP in Action =====

Now ping the client again:

<syntaxhighlight lang="bash">ping -c 1 10.0.0.2</syntaxhighlight>
This ping should succeed. Immediately check the neighbor table:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
The entry for <code>10.0.0.2</code> has been automatically recreated. The kernel performed ARP resolution transparently during the ping.


===== Common ARP Issues =====

When troubleshooting connectivity:

# If <code>ping</code> shows "Destination Host Unreachable", check <code>ip neigh</code>. If the entry is <code>FAILED</code>, the remote host isn't responding to ARP requests (possibly down, wrong subnet, or firewall blocking ARP).
# If <code>ping</code> works but other services don't, ARP isn't the problem—look at routing or firewall rules.
# If connectivity is intermittent, check for duplicate IP addresses (two devices responding to the same IP).


==== Deliverable C: ====

After following exercise 3, provide the output of:

<syntaxhighlight lang="bash">ip neigh show
sudo ip neigh flush all
ip neigh show # Should be empty or show failed entries
ping -c 1 10.0.0.2
ip neigh show # Should show REACHABLE entry</syntaxhighlight>

=== Exercise 4: Routing and Gateway Configuration ===


==== Theory: Beyond the Local Network ====

So far, our host and client can communicate because they're in the same subnet (10.0.0.0/24). But what happens when you try to reach an IP address that doesn't match any of your local subnets? For example, how do you reach the internet (like Google's DNS server at 8.8.8.8)?


===== The Routing Table =====

The routing table is a kernel data structure that maps destination networks to interfaces and gateways. When the kernel needs to send a packet, it consults this table to decide where to send it.

Each routing table entry specifies:

* '''Destination network''': Which IP addresses this route applies to (e.g., <code>10.0.0.0/24</code> or <code>0.0.0.0/0</code> for default)
* '''Gateway''': The IP address of the router to forward packets through (or "direct" if no gateway needed)
* '''Interface''': Which network interface to send packets out
* '''Metric''': Priority when multiple routes match (lower is preferred)

View the routing table:

<syntaxhighlight lang="bash">ip route show</syntaxhighlight>
Or the older command:

<syntaxhighlight lang="bash">route -n</syntaxhighlight>
Example output:

<pre>default via 192.168.1.1 dev eth0 metric 100
10.0.0.0/24 dev v-host proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50</pre>
Let's decode this:

* <code>default via 192.168.1.1 dev eth0</code>: For any destination not matched by more specific routes, forward packets to the gateway at 192.168.1.1 through interface eth0. This is called the "default route" or "default gateway."
* <code>10.0.0.0/24 dev v-host</code>: For destinations in 10.0.0.0/24, send directly out v-host (no gateway needed). This route was automatically created when we assigned 10.0.0.1/24 to v-host.
* <code>192.168.1.0/24 dev eth0</code>: Local network, send directly out eth0.


===== The Default Route =====

The default route (destination <code>0.0.0.0/0</code> or shown as <code>default</code>) is the "route of last resort." It's a catch-all that matches any destination not covered by more specific routes. Without a default route, the kernel can only reach directly connected networks.

The gateway specified in the default route must itself be reachable via a local network. You can't set a gateway to an IP address that the kernel doesn't know how to reach.

How Routing Decisions Work

When sending a packet to destination IP D:

# The kernel searches the routing table for the most specific match (longest prefix match)
# If a match is found, use that route's interface and gateway
# If no match is found and no default route exists, return "Network is unreachable" error

Example: Routing to 8.8.8.8

* Check local routes: Does 8.8.8.8 match 10.0.0.0/24? No. Does it match 192.168.1.0/24? No.
* Check default route: Yes, <code>default</code> matches everything
* Use the default route: Send packet to gateway 192.168.1.1 via eth0


===== Network Address Translation (NAT) =====

Private IP addresses (like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are not routable on the public internet. If the client (10.0.0.2) wants to reach Google (8.8.8.8), it faces a problem: Google's servers can't send replies back to 10.0.0.2 because that address is private and potentially used by millions of devices worldwide.

The solution is NAT (Network Address Translation), specifically a technique called "masquerading":

# The client sends a packet to 8.8.8.8 with source IP 10.0.0.2
# The packet reaches the host (acting as a router/gateway)
# The host '''rewrites''' the source IP from 10.0.0.2 to its own public IP (e.g., 203.0.113.5)
# The host forwards the packet to the internet
# Google replies to 203.0.113.5
# The host receives the reply, recognizes it belongs to the client's connection, rewrites the destination IP back to 10.0.0.2, and forwards it to the client

This source IP rewriting is called "masquerading" because the host "masks" the private IP behind its own public IP. The host maintains a connection table to track which internal client made which request.


===== IP Forwarding =====

For the host to act as a router, the kernel must be configured to forward packets between interfaces. By default, Linux does not forward (for security reasons). We enable it with:

<syntaxhighlight lang="bash">sudo sysctl -w net.ipv4.ip_forward=1</syntaxhighlight>
This setting tells the kernel: "If a packet arrives on one interface and is destined for an address reachable via another interface, forward it."


==== Practice: Enabling Internet Access ====


===== Step 1: The Problem - No Route =====

From the client namespace, try to ping Google's DNS server:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 2 8.8.8.8</syntaxhighlight>
Result: <code>connect: Network is unreachable</code>

Why? Let's check the client's routing table:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route show</syntaxhighlight>
You should see only:

<pre>10.0.0.0/24 dev v-client proto kernel scope link src 10.0.0.2</pre>
This means the client knows how to reach 10.0.0.0/24, but it has no idea how to reach 8.8.8.8. There's no default route.


===== Step 2: Add a Default Route =====

Tell the client to use the host (10.0.0.1) as its default gateway:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route add default via 10.0.0.1</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route show</syntaxhighlight>
You should now see:

<pre>default via 10.0.0.1 dev v-client
10.0.0.0/24 dev v-client proto kernel scope link src 10.0.0.2</pre>
This tells the kernel: "For any destination I don't have a specific route for, send it to 10.0.0.1."


===== Step 3: The Problem - No Forwarding =====

Try pinging again:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 2 8.8.8.8</syntaxhighlight>
It might still fail or timeout. Why? Even though the client sends packets to the host, the host might not be forwarding them. Let's enable IP forwarding on the host:

<syntaxhighlight lang="bash">sudo sysctl -w net.ipv4.ip_forward=1</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">sysctl net.ipv4.ip_forward</syntaxhighlight>
Should show: <code>net.ipv4.ip_forward = 1</code>


===== Step 4: The Problem - No NAT =====

Try pinging again:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 2 8.8.8.8</syntaxhighlight>
It still might not work. The packets are being forwarded, but they have source IP 10.0.0.2. The internet routers don't know how to route replies back to private IP addresses. We need NAT.


===== Step 5: Configure NAT (Masquerade) =====

We'll use nftables to configure NAT. First, identify your internet-connected interface (replace <code>eth0</code> if yours is different):

<syntaxhighlight lang="bash">ip route show default</syntaxhighlight>
Look for <code>default via X.X.X.X dev INTERFACE</code>. Note the interface name (e.g., <code>eth0</code>).

Now configure NAT to masquerade traffic from the 10.0.0.0/24 subnet going out your internet interface:

<syntaxhighlight lang="bash">sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; }
sudo nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "eth0" masquerade</syntaxhighlight>
'''Important''': Replace <code>"eth0"</code> with your actual internet interface name.

The nftables interface is a complex and powerful kernel tool for firewall and NAT managment. Understanding exactly how this works is beyond the scope of this lab. For now, use the commands aboce "as-is".

Verify the rule:

<syntaxhighlight lang="bash">sudo nft list ruleset</syntaxhighlight>

===== Step 6: Success! =====

Now try pinging from the client:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 3 8.8.8.8</syntaxhighlight>
Success! The client can now reach the internet.

What Just Happened?

When the client pings 8.8.8.8:

# Client kernel checks routing table, finds default route via 10.0.0.1
# Client sends packet to 10.0.0.1 (the host)
# Host receives packet, checks if IP forwarding is enabled (yes)
# Host checks its routing table for 8.8.8.8, finds default route via internet gateway
# Host's nftables NAT rule rewrites source IP from 10.0.0.2 to host's public IP
# Host forwards packet to internet gateway
# Packet reaches 8.8.8.8, reply comes back to host's public IP
# Host's NAT table recognizes this is a reply to client's connection
# Host rewrites destination IP from host's public IP back to 10.0.0.2
# Host forwards reply to client via v-host interface

All of this happens transparently at wire speed, managed by the kernel.


==== Deliverable D ====

After following exercise 4, provide the output of:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route show
sudo ip netns exec client_ns ping -c 3 8.8.8.8</syntaxhighlight>

=== Exercise 5: Virtual Switches (Linux Bridge) ===


==== Theory: Hub-and-Spoke vs. Switched Networks ====

So far, we've created a simple point-to-point connection using a veth pair. This works for connecting two devices, but what if we want to connect multiple devices? We could create veth pairs between every pair of devices, but that's not scalable. A three-device network would need 3 pairs, a four-device network would need 6 pairs, and so on.

The traditional solution is a network switch.


===== Physical vs. Virtual Switches =====

A physical Ethernet switch is a hardware device with multiple ports. When it receives a frame on one port, it examines the destination MAC address and forwards the frame only to the port where that MAC address is located. The switch learns MAC address locations by observing source addresses on incoming frames.

A Linux bridge is a software implementation of a network switch. It's a virtual interface that you can "plug" other interfaces into. The bridge learns MAC addresses and forwards frames intelligently, just like a physical switch.

Key characteristics of a bridge:

* Operates at the network level (MAC addresses)
* Supports multiple connected interfaces
* Learns MAC addresses dynamically
* Provides broadcast domain for protocols like ARP
* Transparent to IP protocols

Creating a Switched Topology

In this exercise, we'll recreate our network with a proper switched architecture:

<pre> [Host]
|
| v-host (connected to br-lab)
|
[br-lab] (bridge/switch)
|
+--- v-red-br ~~~ v-red-ns ----> [Red NS]
|
+--- v-blue-br ~~~ v-blue-ns ---> [Blue NS]</pre>
The bridge (<code>br-lab</code>) acts as a switch. The host, red namespace, and blue namespace are all "plugged into" different ports of this virtual switch.

Why This Matters

This architecture mirrors real networks:

* Home networks: Your home router has a built-in switch connecting your devices
* Data centers: Switches connect servers to network backbones
* Cloud environments: Virtual switches (like Open vSwitch) connect containers and VMs
* Container orchestration: Docker and Kubernetes use Linux bridges for container networking

Understanding bridges is essential for working with modern virtualization and containerization technologies.


==== Practice: Building a Switched Network ====


===== Step 1: Clean Up Previous Configuration =====

Remove the old point-to-point setup:

<syntaxhighlight lang="bash">sudo ip netns delete client_ns
sudo ip link delete v-host</syntaxhighlight>
The veth pair is automatically cleaned up when we delete v-host (since they're paired).

Verify:

<syntaxhighlight lang="bash">ip netns list
ip link show | grep v-</syntaxhighlight>
Both should show no results.


===== Step 2: Create the Bridge (Virtual Switch) =====

Create a Linux bridge named <code>br-lab</code>:

<syntaxhighlight lang="bash">sudo ip link add name br-lab type bridge</syntaxhighlight>
Bring it up:

<syntaxhighlight lang="bash">sudo ip link set br-lab up</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">ip link show br-lab</syntaxhighlight>
You should see a new interface of type <code>bridge</code> in state UP.


===== Step 3: Create Network Namespaces for Two Clients =====

Create namespaces for "red" and "blue" clients:

<syntaxhighlight lang="bash">sudo ip netns add red
sudo ip netns add blue</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">ip netns list</syntaxhighlight>

===== Step 4: Create and Connect Red Client =====

Create a veth pair for the red client:

<syntaxhighlight lang="bash">sudo ip link add v-red-br type veth peer name v-red-ns</syntaxhighlight>
Connect one end (<code>v-red-br</code>) to the bridge:

<syntaxhighlight lang="bash">sudo ip link set v-red-br master br-lab</syntaxhighlight>
This "plugs" v-red-br into the switch. The <code>master</code> keyword means "this interface is now a port of the bridge."

Move the other end into the red namespace:

<syntaxhighlight lang="bash">sudo ip link set v-red-ns netns red</syntaxhighlight>
Bring up the bridge-side interface:

<syntaxhighlight lang="bash">sudo ip link set v-red-br up</syntaxhighlight>
Assign IP to red client and bring it up:

<syntaxhighlight lang="bash">sudo ip netns exec red ip addr add 10.0.0.2/24 dev v-red-ns
sudo ip netns exec red ip link set v-red-ns up
sudo ip netns exec red ip link set lo up</syntaxhighlight>

===== Step 5: Create and Connect Blue Client =====

Repeat the same process for blue:

<syntaxhighlight lang="bash">sudo ip link add v-blue-br type veth peer name v-blue-ns
sudo ip link set v-blue-br master br-lab
sudo ip link set v-blue-ns netns blue
sudo ip link set v-blue-br up
sudo ip netns exec blue ip addr add 10.0.0.3/24 dev v-blue-ns
sudo ip netns exec blue ip link set v-blue-ns up
sudo ip netns exec blue ip link set lo up</syntaxhighlight>

===== Step 6: Configure the Host Interface =====

The host also needs to be connected to the switch. We'll assign an IP address directly to the bridge interface:

<syntaxhighlight lang="bash">sudo ip addr add 10.0.0.1/24 dev br-lab</syntaxhighlight>
Why does this work? A bridge can have an IP address, making the host itself a participant on the switched network. This is simpler than creating another veth pair.


===== Step 7: Verify the Topology =====

Check bridge status:

<syntaxhighlight lang="bash">ip link show master br-lab</syntaxhighlight>
This shows all interfaces connected to the bridge. You should see <code>v-red-br</code> and <code>v-blue-br</code>.

Or use the bridge utility:

<syntaxhighlight lang="bash">bridge link show</syntaxhighlight>
Check IP addresses:

<syntaxhighlight lang="bash">ip addr show br-lab
sudo ip netns exec red ip addr show v-red-ns
sudo ip netns exec blue ip addr show v-blue-ns</syntaxhighlight>

===== Step 8: Test Connectivity =====

Red to Blue (peer-to-peer):

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 3 10.0.0.3</syntaxhighlight>
Blue to Red:

<syntaxhighlight lang="bash">sudo ip netns exec blue ping -c 3 10.0.0.2</syntaxhighlight>
Red to Host:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 3 10.0.0.1</syntaxhighlight>
Blue to Host:

<syntaxhighlight lang="bash">sudo ip netns exec blue ping -c 3 10.0.0.1</syntaxhighlight>
All of these should succeed. The bridge is forwarding frames between all three participants.

Host to Red:

<syntaxhighlight lang="bash">ping -c 3 10.0.0.2</syntaxhighlight>
Host to Blue:

<syntaxhighlight lang="bash">ping -c 3 10.0.0.3</syntaxhighlight>

===== Step 9: Enable Internet Access for Clients =====

Add default routes for both clients:

<syntaxhighlight lang="bash">sudo ip netns exec red ip route add default via 10.0.0.1
sudo ip netns exec blue ip route add default via 10.0.0.1</syntaxhighlight>
Verify IP forwarding is still enabled (should be from Exercise 4):

<syntaxhighlight lang="bash">sysctl net.ipv4.ip_forward</syntaxhighlight>
If not set to 1, enable it:

<syntaxhighlight lang="bash">sudo sysctl -w net.ipv4.ip_forward=1</syntaxhighlight>
Ensure NAT is still configured (should be from Exercise 4):

<syntaxhighlight lang="bash">sudo nft list ruleset | grep masquerade</syntaxhighlight>
If not present, add it again (replace <code>eth0</code> with your internet interface):

<syntaxhighlight lang="bash">sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; }
sudo nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "eth0" masquerade</syntaxhighlight>
Test internet access:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 3 8.8.8.8
sudo ip netns exec blue ping -c 3 8.8.8.8</syntaxhighlight>
Both clients can now reach the internet through the host, which acts as both a switch (via the bridge) and a router (via IP forwarding and NAT).

Understanding the Data Flow

When Red (10.0.0.2) pings Blue (10.0.0.3):

# Red's kernel sees 10.0.0.3 is in the local subnet, sends ARP request
# ARP request goes out v-red-ns, through the veth pair to v-red-br
# v-red-br is connected to br-lab (the switch)
# br-lab broadcasts the ARP request to all connected interfaces (v-blue-br and itself)
# Blue receives ARP request via v-blue-ns, replies with its MAC
# br-lab learns Blue's MAC address is on port v-blue-br
# Subsequent packets from Red to Blue are forwarded directly to v-blue-br (no broadcast)
# The bridge maintains a MAC address table, just like a physical switch

When Red (10.0.0.2) pings Google (8.8.8.8):

# Red's kernel sees 8.8.8.8 is not in the local subnet, consults routing table
# Default route says to send to gateway 10.0.0.1 (the host)
# Red uses ARP to find MAC of 10.0.0.1
# Packet goes through veth pair to br-lab
# br-lab forwards to its own IP (10.0.0.1 is assigned to br-lab)
# Host kernel receives packet, sees it's destined for 8.8.8.8
# IP forwarding is enabled, so host checks routing table
# Host finds default route via internet gateway
# NAT rule rewrites source IP from 10.0.0.2 to host's public IP
# Packet forwarded to internet


=== Scripting Challenges ===

These challenges test your ability to automate network configuration and extract useful diagnostic information from the kernel's network subsystem.


==== Challenge 1: Automated Network Builder ====

Write a bash script <code>lab7_builder.sh</code> that automatically constructs the Red/Blue/Bridge topology from Exercise 5, assigns IP addresses, enables routing and NAT, and provides cleanup functionality.

Requirements:

# '''Script Name ''': <code>lab7_builder.sh</code>
# '''Shebang and Best Practices''':
#* Start with <code>#!/bin/bash</code>
#* Use <code>set -euo pipefail</code> for error handling
# '''Arguments''':
#* <code>start</code>: Create and configure the network
#* <code>stop</code>: Clean up all created resources
# '''Start Operation Must''':
#* Create bridge <code>br-lab</code>
#* Create namespaces <code>red</code> and <code>blue</code>
#* Create veth pairs and connect them to the bridge and namespaces
#* Assign IP addresses:
#** Host (br-lab): 10.0.0.1/24
#** Red: 10.0.0.2/24
#** Blue: 10.0.0.3/24
#* Bring all interfaces UP
#* Add default routes for both clients pointing to 10.0.0.1
#* Enable IP forwarding
#* Configure NAT/masquerade for 10.0.0.0/24 traffic going out the default internet interface
#* Print a success message: "Network topology created successfully"
# '''Stop Operation Must''':
#* Delete namespaces (this automatically removes interfaces inside them)
#* Delete bridge
#* Flush nftables nat table
#* Disable IP forwarding (set back to 0)
#* Print a success message: "Network topology cleaned up successfully"

Testing:

<syntaxhighlight lang="bash">chmod +x ./lab7_builder.sh
sudo ./lab7_builder.sh start
sudo ip netns exec red ping -c 2 10.0.0.3
sudo ip netns exec red ping -c 2 8.8.8.8
sudo ./lab7_builder.sh stop</syntaxhighlight>

===== Deliverable Challenge 1: =====

* Complete script source code with comments
* Output of running the script with <code>start</code> argument
* Output of connectivity tests (red to blue, red to internet)
* Output of running the script with <code>stop</code> argument


==== Challenge 2: Namespace Inspector ====

Write a bash script <code>lab7_inspect.sh</code> that takes a namespace name as an argument and displays diagnostic information about that namespace's network configuration.

Requirements:

<ol style="list-style-type: decimal;">
<li>'''Script Name''': <code>lab7_inspect.sh</code></li>
<li>'''Shebang and Best Practices''':
<ul>
<li>Start with <code>#!/bin/bash</code></li>
<li>Use <code>set -euo pipefail</code></li>
<li>Use functions</li>
<li>Comment your code</li></ul>
</li>
<li>'''Arguments''':
<ul>
<li>Takes exactly one argument: the namespace name</li>
<li>If no argument or more than one argument, print usage and exit with error</li></ul>
</li>
<li>'''Output Format''' (exactly as shown):
<pre>=== Network Inspection for Namespace: <ns_name> ===

[Interfaces]
<output of ip link show>

[IP Addresses]
<output of ip addr show>

[Routes]
<output of ip route show>

[Default Gateway]
<extract and show only the default gateway IP, or "None" if not configured>

[Neighbors (ARP Cache)]
<output of ip neigh show></pre></li>
<li>'''Functionality''':
<ul>
<li>Check if namespace exists before attempting to inspect</li>
<li>All commands should run inside the specified namespace</li>
<li>Extract the default gateway IP from the routing table (hint: grep for "default" and extract the IP after "via")</li></ul>
</li></ol>

Testing (after running Challenge 1's start command):

<syntaxhighlight lang="bash">chmod +x ./lab7_inspect.sh
sudo ./lab7_inspect.sh red
sudo ./lab7_inspect.sh blue</syntaxhighlight>

====== Deliverable Challenge 2: ======

* Complete script source code with comments
* Output of running the script for the <code>red</code> namespace (after pinging a few addresses to populate ARP cache)


== Reference: Network Command Quick Guide ==

This section provides a quick reference for the commands introduced in this lab.


=== Interface Management (ip link) ===

<syntaxhighlight lang="bash"># List all interfaces
ip link show

# Create veth pair
sudo ip link add dev <name1> type veth peer name <name2>

# Move interface to namespace
sudo ip link set <interface> netns <namespace>

# Bring interface up/down
sudo ip link set <interface> up
sudo ip link set <interface> down

# Delete interface
sudo ip link delete <interface>

# Create bridge
sudo ip link add name <bridge> type bridge

# Connect interface to bridge
sudo ip link set <interface> master <bridge></syntaxhighlight>

=== Address Management (ip addr) ===

<syntaxhighlight lang="bash"># Show addresses
ip addr show
ip addr show <interface>

# Add address
sudo ip addr add <ip>/<prefix> dev <interface>
# Example: sudo ip addr add 10.0.0.1/24 dev eth0

# Remove address
sudo ip addr del <ip>/<prefix> dev <interface>

# Flush all addresses from interface
sudo ip addr flush dev <interface></syntaxhighlight>

=== Routing Management (ip route) ===

<syntaxhighlight lang="bash"># Show routing table
ip route show

# Add route
sudo ip route add <network>/<prefix> via <gateway>
# Example: sudo ip route add 192.168.2.0/24 via 192.168.1.1

# Add default route
sudo ip route add default via <gateway>
# Example: sudo ip route add default via 10.0.0.1

# Delete route
sudo ip route del <network>/<prefix>
sudo ip route del default

# Flush routing table
sudo ip route flush table main</syntaxhighlight>

=== Neighbor Management (ip neigh) ===

<syntaxhighlight lang="bash"># Show ARP cache
ip neigh show

# Flush ARP cache
sudo ip neigh flush all

# Add static ARP entry
sudo ip neigh add <ip> lladdr <mac> dev <interface>

# Delete ARP entry
sudo ip neigh del <ip> dev <interface></syntaxhighlight>

=== Namespace Management (ip netns) ===

<syntaxhighlight lang="bash"># List namespaces
ip netns list

# Create namespace
sudo ip netns add <name>

# Delete namespace
sudo ip netns delete <name>

# Execute command in namespace
sudo ip netns exec <name> <command>
# Example: sudo ip netns exec red ping 10.0.0.1

# Get shell in namespace
sudo ip netns exec <name> bash</syntaxhighlight>

=== Bridge Management ===

<syntaxhighlight lang="bash"># Show bridge details
bridge link show
bridge fdb show # Show MAC address table

# Show which interfaces are part of a bridge
ip link show master <bridge></syntaxhighlight>

=== IP Forwarding ===

<syntaxhighlight lang="bash"># Check status
sysctl net.ipv4.ip_forward

# Enable (temporary)
sudo sysctl -w net.ipv4.ip_forward=1

# Disable
sudo sysctl -w net.ipv4.ip_forward=0

# Enable permanently (edit /etc/sysctl.conf)
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf</syntaxhighlight>

=== NAT with nftables ===

<syntaxhighlight lang="bash"># List current ruleset
sudo nft list ruleset

# Create NAT table and rules
sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; }
sudo nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "eth0" masquerade

# Delete NAT table
sudo nft delete table ip nat

# Flush ruleset
sudo nft flush ruleset</syntaxhighlight>

=== Diagnostic Tools ===

<syntaxhighlight lang="bash"># Test connectivity
ping -c 3 <ip>

# Trace route
traceroute <ip>

# Show listening sockets
ss -tuln

# Monitor traffic
sudo tcpdump -i <interface>
sudo tcpdump -i <interface> -n arp # Show only ARP traffic
sudo tcpdump -i <interface> -n icmp # Show only ping traffic

# Show interface statistics
ip -s link show <interface></syntaxhighlight>

== Common Network Topology Patterns ==


=== Point-to-Point Connection ===

<pre>[Host] <---veth pair---> [Namespace]</pre>
Use case: Simple container isolation, testing


=== Switched Network ===

<pre> [Bridge]
|
+-------+-------+
| | |
[Host] [NS1] [NS2]</pre>
Use case: Multiple containers/VMs on same network


=== Routed Network ===

<pre>[Internet] <---> [Host/Router] <---> [Bridge] <---> [Containers]
(NAT)</pre>
Use case: Containers with internet access


== Summary Table: Network Components ==

{| class="wikitable"
|-
! Component
! Purpose
! Layer
! Key Commands
|-
| veth pair
| Virtual cable connecting two interfaces
| L2
| <code>ip link add type veth</code>
|-
| bridge
| Virtual switch
| L2
| <code>ip link add type bridge</code>
|-
| IP address
| Device identity and subnet membership
| L3
| <code>ip addr add</code>
|-
| Route
| Path determination
| L3
| <code>ip route add</code>
|-
| ARP/Neighbor
| IP-to-MAC mapping
| L2/L3
| <code>ip neigh show</code>
|-
| NAT
| Private-to-public IP translation
| L3
| <code>nft add rule masquerade</code>
|-
| Namespace
| Isolated network stack
| All
| <code>ip netns add</code>
|}


== Deliverables and Assessment ==

Submit a single PDF document containing:

The deliverables A-D and solutions to the challanges 1 and 2.


== For further study: ==

'''Advanced Topics''':

* VLANs and 802.1Q tagging
* Open vSwitch (OVS) for advanced switching
* Network policies and firewalling with nftables
* Quality of Service (QoS) and traffic shaping
* IPv6 configuration and dual-stack networking
* VPN setup with WireGuard or OpenVPN

'''Container Networking''':

* Docker networking modes (bridge, host, overlay)
* Kubernetes networking model and CNI plugins
* Service meshes (Istio, Linkerd)

'''Performance and Monitoring''':

* Network performance testing with iperf
* Packet capture and analysis with Wireshark
* Continuous monitoring with Prometheus and Grafana

'''Security''':

* Network segmentation and isolation
* Firewall rule design
* Intrusion detection systems
* Zero-trust networking


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 8 ip # iproute2 command reference
man 8 ip-link # Interface management
man 8 ip-address # Address management
man 8 ip-route # Routing management
man 8 ip-netns # Namespace management
man 8 bridge # Bridge management
man 7 netdevice # Network device overview
man 7 arp # ARP protocol
man 5 nft # nftables syntax
man 8 tcpdump # Packet capture</syntaxhighlight>

=== Online Resources: ===

* [https://lartc.org/ Linux Advanced Routing & Traffic Control HOWTO]
* [https://wiki.linuxfoundation.org/networking/iproute2 iproute2 documentation]
* [https://www.kernel.org/doc/html/latest/networking/ The Linux Kernel Networking Stack]
* [https://wiki.nftables.org/ nftables Wiki]

OS Lab 7 - The Network Subsystem

2025-11-21T14:49:06Z

Vserbu: Pagină nouă: == Objectives == Upon completion of this lab, you will be able to: * Explain how the kernel represents network abstractions: Interfaces, Addresses,...

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how the kernel represents network abstractions: Interfaces, Addresses, Routes, and Neighbors.
* Use the modern iproute2 suite (<code>ip link</code>, <code>ip addr</code>, <code>ip route</code>, <code>ip neigh</code>) to manage kernel network objects.
* Create isolated network environments using Network Namespaces to simulate multiple virtual computers.
* Construct a complete virtual network topology (Switch, Router, NAT) from scratch using OS primitives.
* Diagnose connectivity issues by inspecting the ARP cache and Routing table to understand packet delivery.
* Understand the relationship between Layer 2 (MAC addresses) and Layer 3 (IP addresses) networking.


== Introduction ==

In Lab 6, we explored Inter-Process Communication (IPC) mechanisms that allow processes to exchange data and coordinate their actions. We touched briefly on Sockets, which extend IPC beyond a single machine by enabling communication across network boundaries. However, using sockets effectively requires understanding what happens beneath the abstraction: how does data actually travel from one machine to another?

The answer lies in the kernel's network stack, a complex subsystem responsible for managing network interfaces, addressing, routing, and protocol handling. Usually, the network stack is configured automatically by background services like NetworkManager, systemd-networkd, or DHCP clients. These tools shield users from complexity, but they also obscure the fundamental mechanisms at work.

In this lab, we peel back those layers to interact directly with the kernel's networking subsystem. We will not use physical network cables or hardware switches. Instead, we will use the operating system itself to manufacture virtual hardware—virtual network cards, virtual cables, and virtual switches. By constructing networks programmatically, we gain deep insight into how the kernel manages connectivity, routing, and address resolution.

This lab is structured around a progression: we start with a simple point-to-point connection between two virtual machines, then evolve it into a switched network with multiple clients, routing capabilities, and internet access via Network Address Translation (NAT). Along the way, we examine the kernel's internal state at each step to understand exactly how packets flow through the system.

Understanding the network subsystem is essential for system administration, DevOps, container orchestration (Docker, Kubernetes), network troubleshooting, and security. These same primitives underlie modern cloud networking, virtual private networks, and service meshes.


== Prerequisites ==


=== System Requirements ===

A running instance of Linux machine with root privileges (via <code>sudo</code>).


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y iproute2 iputils-ping traceroute nftables</syntaxhighlight>
* <code>iproute2</code>: The modern suite for network configuration, replacing legacy tools like <code>ifconfig</code> and <code>route</code>. Provides <code>ip</code> command.
* <code>iputils-ping</code>: Provides the <code>ping</code> utility for testing connectivity.
* <code>traceroute</code>: Maps the path packets take through networks.
* <code>nftables</code>: The modern Linux firewall/NAT framework.


== Knowledge Prerequisites ==

You should be familiar with:

* Process concepts from Lab 3 (PIDs, process hierarchy)
* File permissions from Lab 4 (execute bit, ownership)
* Bash scripting from Lab 5 (shebangs, variables, loops, functions)
* IPC concepts from Lab 6 (understanding of how processes communicate)


== The Network Subsystem: Kernel Fundamentals ==


==== What is a Network? ====

To the Linux kernel, a "Network" is not a physical thing—it's an abstraction representing a group of computers that can communicate with each other directly, without requiring a router as an intermediary. This direct communication capability is what defines a network segment or broadcast domain.

A single computer can participate in multiple networks simultaneously. It simply needs a separate Network Interface for each network it wants to join. Think of interfaces as "plugs" or "sockets" that connect your computer to different communication channels.


==== The Four Pillars of Networking ====

The kernel's network subsystem is built on four fundamental abstractions. Understanding these is key to mastering network configuration:

# '''Interfaces''': The physical or virtual network adapters that can send and receive packets. Each interface represents a connection point to a network.
# '''Addresses''': IP addresses assigned to interfaces, giving them identities on the network. Addresses define "who" you are.
# '''Routes''': Kernel rules that determine which interface should be used to reach a given destination. Routes define "how to get there."
# '''Neighbors''': The kernel's cache mapping IP addresses to MAC addresses for direct communication. Neighbors define "where exactly on this wire."

These four abstractions work together. When you send a packet to an IP address:

# The kernel consults the '''Routing Table''' to determine which '''Interface''' to use.
# If the route indicates the destination is local (directly reachable), the kernel consults the '''Neighbor Table''' to find the MAC address.
# If the MAC address is unknown, the kernel uses ARP (Address Resolution Protocol) to discover it.
# The kernel constructs an Ethernet frame with the destination MAC address and sends it out the chosen '''Interface'''.


==== The iproute2 Suite: Modern Network Management ====

Historically, Linux used separate commands for each aspect of networking: <code>ifconfig</code> for interfaces, <code>route</code> for routing, <code>arp</code> for neighbors. These tools are now considered legacy. Modern Linux uses the unified <code>iproute2</code> suite, centered around the <code>ip</code> command.

The <code>ip</code> command uses a consistent syntax:

<syntaxhighlight lang="bash">ip OBJECT COMMAND [OPTIONS]</syntaxhighlight>
Where OBJECT is one of:

* <code>link</code>: Network interfaces (Layer 2)
* <code>addr</code> or <code>address</code>: IP addresses (Layer 3)
* <code>route</code>: Routing table entries
* <code>neigh</code> or <code>neighbour</code>: ARP/Neighbor cache

Common commands:

* <code>ip link show</code>: List all network interfaces
* <code>ip addr show</code>: Show IP addresses assigned to interfaces
* <code>ip route show</code>: Display the routing table
* <code>ip neigh show</code>: Display the neighbor (ARP) cache

The beauty of <code>ip</code> is that it provides a consistent, scriptable interface to the kernel's network state. Unlike older tools, <code>ip</code> is designed for automation and parsing by scripts.


==== Network Namespaces: Virtual Computers ====

A Network Namespace (often abbreviated "netns") is a kernel feature that creates an isolated copy of the network stack. Each namespace has its own:

* Set of network interfaces
* Routing table
* ARP cache
* Firewall rules
* Socket listening ports

From the kernel's perspective, a network namespace is effectively a separate "Virtual Computer" with its own completely independent networking configuration. Processes running inside a namespace cannot see or interact with interfaces or connections in other namespaces (unless explicitly bridged).

Your Linux host runs in the "default" or "root" namespace. When you run <code>ip link show</code> normally, you see the default namespace's interfaces. But we can create new namespaces to simulate remote machines for testing, all on a single physical computer.

Network namespaces are the foundation of container networking. When you run a Docker container, Docker creates a new network namespace for it, giving the container its own isolated network stack.

Commands for working with namespaces:

* <code>ip netns add NAME</code>: Create a new namespace
* <code>ip netns list</code>: List all namespaces
* <code>ip netns exec NAME COMMAND</code>: Execute a command inside a namespace
* <code>ip netns delete NAME</code>: Remove a namespace

When you execute a command with <code>ip netns exec client_ns ip link</code>, you're running the <code>ip link</code> command inside the <code>client_ns</code> namespace, so it sees only that namespace's interfaces.


== Hands-on Exercises ==

In this lab, we will start by building a simple direct connection between two virtual computers, then evolve it step-by-step into a complex switched network with routing and NAT.


=== Exercise 1: Network Interfaces and Virtual Cables ===


==== Theory: The Virtual Ethernet (veth) Pair ====

Physical networks require network interface cards (NICs) and physical cables. Virtual networks require virtual equivalents. The Linux kernel provides several types of virtual interfaces:

* '''veth (Virtual Ethernet) pairs''': A veth pair is like a virtual patch cable with two ends. Packets sent into one end immediately come out the other end. veth pairs are the fundamental building block for connecting network namespaces.
* '''bridges''': Virtual switches that connect multiple interfaces together.
* '''tun/tap devices''': Virtual interfaces used by userspace programs (like VPNs).
* '''vlan devices''': Virtual interfaces representing 802.1Q VLAN tags.

In this exercise, we focus on veth pairs. When you create a veth pair, the kernel creates two interfaces that are permanently wired together. You can place these interfaces in different namespaces, effectively running a "cable" between two virtual machines.

Every network interface, physical or virtual, has several properties:

* '''Name''': The interface identifier (e.g., <code>eth0</code>, <code>v-host</code>)
* '''MAC Address''': A Layer 2 hardware address (48 bits, typically written as six hex pairs like <code>aa:bb:cc:dd:ee:ff</code>)
* '''State''': UP (enabled) or DOWN (disabled)
* '''MTU''': Maximum Transmission Unit, the largest packet size the interface can handle

Even virtual interfaces have MAC addresses. The kernel auto-generates them, though you can set them manually if needed.


==== Practice: Creating Your First Virtual Network ====

We will create two virtual computers: your host (running in the default namespace) and a client (running in a new namespace called <code>client_ns</code>). We'll connect them with a veth pair.


===== Step 1: Examine Your Current Network Configuration =====

Before we begin constructing virtual networks, let's see what we're starting with:

<syntaxhighlight lang="bash">ip link show</syntaxhighlight>
You should see at least two interfaces:

* <code>lo</code>: The loopback interface (127.0.0.1), used for local communication within the machine
* <code>eth0</code> (or <code>ens33</code>, <code>enp0s3</code>, etc.): Your primary physical (or virtualized) network interface connected to the outside world

Note the MAC addresses, the state (UP or DOWN), and the MTU (typically 1500 bytes for Ethernet).

Each interface has an "ifindex" number, which is the kernel's internal identifier. You'll see output like:

<pre>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff</pre>
The flags like <code><BROADCAST,MULTICAST,UP,LOWER_UP></code> indicate interface capabilities and state. <code>UP</code> means the interface is enabled, <code>LOWER_UP</code> means the link layer is connected.


===== Step 2: Create a Virtual Ethernet Cable =====

Create a veth pair. This is like manufacturing a network cable with two connectors:

<syntaxhighlight lang="bash">sudo ip link add dev v-host type veth peer name v-client</syntaxhighlight>
Let's break down this command:

* <code>ip link add</code>: Create a new interface
* <code>dev v-host</code>: Name one end "v-host"
* <code>type veth</code>: The interface type is a virtual ethernet pair
* <code>peer name v-client</code>: Name the other end "v-client"

Verify the creation:

<syntaxhighlight lang="bash">ip link show</syntaxhighlight>
You should now see two additional interfaces: <code>v-host</code> and <code>v-client</code>. Both will be in state <code>DOWN</code> initially. Notice that each has been automatically assigned a MAC address by the kernel. These MAC addresses are randomly generated to avoid collisions.

Important: The two interfaces are linked. Packets sent to <code>v-host</code> will appear on <code>v-client</code>, and vice versa. This is how we'll connect our host to the virtual client machine.


===== Step 3: Create a Virtual Computer (Network Namespace) =====

Create a new network namespace to simulate a separate computer:

<syntaxhighlight lang="bash">sudo ip netns add client_ns</syntaxhighlight>
Verify it exists:

<syntaxhighlight lang="bash">ip netns list</syntaxhighlight>
You should see <code>client_ns</code> in the output.

This namespace is now a completely isolated network environment. It has its own set of interfaces (initially just a loopback), its own routing table, and its own ARP cache.

Let's peek inside to see what interfaces exist in the new namespace:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link show</syntaxhighlight>
You should see only the loopback interface (<code>lo</code>). The <code>v-client</code> interface we created is still in the default namespace.


===== Step 4: Connect the Virtual Cable =====

Now we'll "plug" one end of our virtual cable into the virtual computer. We do this by moving the <code>v-client</code> interface from the default namespace into <code>client_ns</code>:

<syntaxhighlight lang="bash">sudo ip link set v-client netns client_ns</syntaxhighlight>
This command transfers ownership of the <code>v-client</code> interface to the <code>client_ns</code> namespace.


===== Step 5: Verify the Topology =====

Verify the change in the default namespace:

<syntaxhighlight lang="bash">ip link show</syntaxhighlight>
Notice that <code>v-client</code> is now '''gone''' from the default namespace. It has moved to <code>client_ns</code>.

Verify inside the namespace:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link show</syntaxhighlight>
Now you should see both <code>lo</code> and <code>v-client</code> inside the namespace.

At this point, we have successfully created a virtual topology:

* '''Host''' (default namespace): Has interface <code>v-host</code>
* '''Client''' (client_ns namespace): Has interface <code>v-client</code>
* '''Connection''': <code>v-host</code> and <code>v-client</code> are connected by a virtual cable

However, neither interface is UP yet, and neither has an IP address. They cannot communicate yet.


==== Deliverable A ====

After following exercise 1, provide the output of the following commands:

<syntaxhighlight lang="bash">ip link show | grep v-host
sudo ip netns exec client_ns ip link show | grep v-client</syntaxhighlight>

=== Exercise 2: IP Addresses and Subnets ===


==== Theory: Identity and Reachability ====

Network interfaces allow computers to physically connect to a network, but to actually communicate, they need identities—IP addresses. An IP address serves two purposes:

# '''Identity''': It uniquely identifies a device on a network (like a phone number)
# '''Routing''': It indicates which network the device belongs to (like an area code)

An IP address by itself is not enough. We also need a subnet mask (or prefix length) that defines the "scope" of the local network—which other IP addresses are directly reachable without routing.


===== Understanding Subnet Masks and CIDR Notation =====

A subnet mask divides an IP address into two parts:

* '''Network portion''': Identifies which network the address belongs to
* '''Host portion''': Identifies the specific device within that network

CIDR (Classless Inter-Domain Routing) notation uses a slash followed by the number of bits in the network portion. For example:

* <code>10.0.0.5/24</code>: The first 24 bits (10.0.0) are the network, leaving 8 bits for hosts (256 addresses: 10.0.0.0 - 10.0.0.255)
* <code>192.168.1.10/16</code>: The first 16 bits (192.168) are the network, leaving 16 bits for hosts (65,536 addresses)
* <code>172.16.0.1/8</code>: The first 8 bits (172) are the network, leaving 24 bits for hosts (16,777,216 addresses)

When you assign an IP address with a prefix length (e.g., <code>10.0.0.1/24</code>), the kernel automatically understands that all addresses matching the network portion (10.0.0.x) are "local" or "directly reachable."


===== The Subnet Decision: How the Kernel Routes Locally =====

When a process wants to send a packet to a destination IP address, the kernel must decide: "Is this destination a neighbor on one of my local networks, or do I need to forward it to a router?"

The kernel's logic:

# For each interface with an assigned IP address and subnet mask, calculate the network address
# Check if the destination IP falls within any of these networks
# If yes → the destination is directly reachable; send the packet out that interface using the destination's MAC address
# If no → consult the routing table for a gateway to forward the packet through

Example: Your interface has IP <code>10.0.0.1/24</code>

* Network: <code>10.0.0.0/24</code> (all addresses from 10.0.0.0 to 10.0.0.255)
* If you ping <code>10.0.0.50</code>: The kernel recognizes this is in the local subnet and sends directly
* If you ping <code>8.8.8.8</code>: The kernel recognizes this is NOT local and looks for a route to a gateway

This automatic local route is created when you assign an IP address. You don't need to manually configure routes for local subnets.


===== Static vs. Dynamic Configuration =====

IP addresses can be configured in two ways:

* '''Static''': Manually assigned by an administrator using <code>ip addr add</code>
* '''Dynamic''': Automatically assigned by a DHCP server

In production systems, DHCP is common because it allows centralized management of address allocation. In this lab, we use static configuration to understand exactly what the kernel is doing.


==== Practice: Assigning IP Addresses ====

We will assign IP addresses to both ends of our virtual cable, placing them in the same subnet so they can communicate directly.


===== Step 1: Understand the Current State =====

Check if any IP addresses are assigned to <code>v-host</code>:

<syntaxhighlight lang="bash">ip addr show v-host</syntaxhighlight>
You should see only the MAC address, no IP addresses. The interface is also DOWN (note <code>state DOWN</code>).

Similarly, check the client:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip addr show v-client</syntaxhighlight>
Same situation: no IP address, interface DOWN.


===== Step 2: Assign IP Address to the Client =====

We'll assign <code>10.0.0.2/24</code> to the client's interface. The <code>/24</code> means the first 24 bits are the network portion, so this device considers all addresses from <code>10.0.0.0</code> to <code>10.0.0.255</code> as local neighbors.

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip addr add 10.0.0.2/24 dev v-client</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip addr show v-client</syntaxhighlight>
You should see:

<pre>inet 10.0.0.2/24 scope global v-client</pre>

===== Step 3: Bring the Client Interface UP =====

Interfaces are created in the DOWN state by default. We must explicitly enable them:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link set v-client up</syntaxhighlight>
Also bring up the loopback interface (required for many network operations):

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link set lo up</syntaxhighlight>
Verify the state changed to UP:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip link show v-client</syntaxhighlight>
Look for <code>state UP</code> in the output.


===== Step 4: Assign IP Address to the Host =====

Now configure the host end of the cable with <code>10.0.0.1/24</code> (same subnet):

<syntaxhighlight lang="bash">sudo ip addr add 10.0.0.1/24 dev v-host</syntaxhighlight>
Bring it up:

<syntaxhighlight lang="bash">sudo ip link set v-host up</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">ip addr show v-host</syntaxhighlight>

===== Step 5: Verify Connectivity =====

The moment of truth. Can the host reach the client?

<syntaxhighlight lang="bash">ping -c 3 10.0.0.2</syntaxhighlight>
If successful, you'll see output like:

<pre>PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.038 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.040 ms</pre>
Congratulations! You've established your first virtual network connection. The host and client can now communicate.

Can the client ping the host?

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 3 10.0.0.1</syntaxhighlight>
This should also succeed. Communication is bidirectional.

Why Does This Work?

Let's trace what happens when you <code>ping 10.0.0.2</code> from the host:

# '''Destination Analysis''': The kernel looks at the destination IP <code>10.0.0.2</code> and your interface <code>v-host</code> with IP <code>10.0.0.1/24</code>. It calculates: "10.0.0.2 is in the 10.0.0.0/24 network, which matches my v-host subnet. This is a local destination."
# '''MAC Address Resolution''': The kernel needs the MAC address of 10.0.0.2. It doesn't know it yet, so it broadcasts an ARP request on <code>v-host</code>: "Who has 10.0.0.2? Please tell 10.0.0.1."
# '''ARP Reply''': The client (in client_ns) receives the ARP request on <code>v-client</code>, recognizes its own IP, and replies: "10.0.0.2 is at MAC address aa:bb:cc:dd:ee:ff" (the MAC of v-client).
# '''Packet Transmission''': Now the host knows the MAC address. It constructs an ICMP Echo Request packet, wraps it in an Ethernet frame addressed to the client's MAC, and sends it out <code>v-host</code>.
# '''Packet Reception''': The packet instantly appears on <code>v-client</code> (because they're a veth pair), travels up the network stack in client_ns, and the kernel processes the ICMP Echo Request.
# '''Reply''': The client sends an ICMP Echo Reply back to 10.0.0.1, using the same process in reverse.

All of this happens in milliseconds, managed entirely by the kernel.


==== Deliverable B ====

After following exercise 2, show the output of the following commands:

<syntaxhighlight lang="bash">ip addr show v-host
sudo ip netns exec client_ns ip addr show v-client
ping -c 3 10.0.0.2</syntaxhighlight>

=== Exercise 3: Neighbor Discovery and ARP ===

So far, we've worked with IP addresses , but the physical network uses MAC addresses. How does the kernel translate between them?


==== Thwory ====


===== The Address Resolution Protocol (ARP) =====

ARP is the protocol that maps IP addresses to MAC addresses on Ethernet networks. When the kernel needs to send a packet to an IP address that it knows is on a local network, it must first discover the target's MAC address.

The ARP process:

# The kernel checks its '''Neighbor Table''' (ARP cache) for an existing entry mapping the destination IP to a MAC address
# If found, use it
# If not found:
#* Broadcast an ARP Request packet on the local network: "Who has IP X.X.X.X? Tell Y.Y.Y.Y."
#* Wait for an ARP Reply: "IP X.X.X.X is at MAC aa:bb:cc:dd:ee:ff"
#* Cache this mapping in the Neighbor Table for future use

ARP is a broadcast protocol at Layer 2. Every device on the local network segment receives the ARP request, but only the device with the matching IP address responds.


===== The Neighbor Table =====

The kernel maintains a Neighbor Table (also called the ARP cache) mapping IP addresses to MAC addresses. Entries have states:

* '''REACHABLE''': The entry is valid and recently confirmed
* '''STALE''': The entry is old but assumed still valid
* '''DELAY''': Awaiting confirmation
* '''INCOMPLETE''': ARP request sent, waiting for reply
* '''FAILED''': ARP request failed, no reply received

Entries automatically expire after a timeout (typically a few minutes of inactivity) to handle cases where devices change MAC addresses or leave the network.

You can view the Neighbor Table with:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
Or the older command:

<syntaxhighlight lang="bash">arp -n</syntaxhighlight>

===== Why ARP Matters for Troubleshooting =====

Many network connectivity issues that seem like "routing problems" are actually ARP problems:

* The kernel can't deliver packets because it never receives an ARP reply
* Stale ARP entries point to the wrong MAC address after a device changes
* ARP conflicts occur when two devices claim the same IP address

Understanding ARP is essential for diagnosing these issues.


==== Practice: Inspecting the ARP Cache ====


===== Step 1: View Current Neighbors =====

Check your neighbor table:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
You should see an entry for <code>10.0.0.2</code> (the client) with its MAC address and state <code>REACHABLE</code>:

<pre>10.0.0.2 dev v-host lladdr aa:bb:cc:dd:ee:ff REACHABLE</pre>
This entry was created when you pinged the client in Exercise 2. The "lladdr" (link-layer address) is the MAC address.

Also check from the client's perspective:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip neigh show</syntaxhighlight>
You should see an entry for <code>10.0.0.1</code> (the host).


===== Step 2: Flush the ARP Cache =====

Let's simulate a situation where the kernel has forgotten the MAC address mappings:

<syntaxhighlight lang="bash">sudo ip neigh flush all</syntaxhighlight>
Verify they're gone:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
The entry for <code>10.0.0.2</code> should be absent or in state <code>FAILED</code> or <code>INCOMPLETE</code>.


===== Step 3: Watch ARP in Action =====

Now ping the client again:

<syntaxhighlight lang="bash">ping -c 1 10.0.0.2</syntaxhighlight>
This ping should succeed. Immediately check the neighbor table:

<syntaxhighlight lang="bash">ip neigh show</syntaxhighlight>
The entry for <code>10.0.0.2</code> has been automatically recreated. The kernel performed ARP resolution transparently during the ping.


===== Common ARP Issues =====

When troubleshooting connectivity:

# If <code>ping</code> shows "Destination Host Unreachable", check <code>ip neigh</code>. If the entry is <code>FAILED</code>, the remote host isn't responding to ARP requests (possibly down, wrong subnet, or firewall blocking ARP).
# If <code>ping</code> works but other services don't, ARP isn't the problem—look at routing or firewall rules.
# If connectivity is intermittent, check for duplicate IP addresses (two devices responding to the same IP).


==== Deliverable C: ====

After following exercise 3, provide the output of:

<syntaxhighlight lang="bash">ip neigh show
sudo ip neigh flush all
ip neigh show # Should be empty or show failed entries
ping -c 1 10.0.0.2
ip neigh show # Should show REACHABLE entry</syntaxhighlight>

=== Exercise 4: Routing and Gateway Configuration ===


==== Theory: Beyond the Local Network ====

So far, our host and client can communicate because they're in the same subnet (10.0.0.0/24). But what happens when you try to reach an IP address that doesn't match any of your local subnets? For example, how do you reach the internet (like Google's DNS server at 8.8.8.8)?


===== The Routing Table =====

The routing table is a kernel data structure that maps destination networks to interfaces and gateways. When the kernel needs to send a packet, it consults this table to decide where to send it.

Each routing table entry specifies:

* '''Destination network''': Which IP addresses this route applies to (e.g., <code>10.0.0.0/24</code> or <code>0.0.0.0/0</code> for default)
* '''Gateway''': The IP address of the router to forward packets through (or "direct" if no gateway needed)
* '''Interface''': Which network interface to send packets out
* '''Metric''': Priority when multiple routes match (lower is preferred)

View the routing table:

<syntaxhighlight lang="bash">ip route show</syntaxhighlight>
Or the older command:

<syntaxhighlight lang="bash">route -n</syntaxhighlight>
Example output:

<pre>default via 192.168.1.1 dev eth0 metric 100
10.0.0.0/24 dev v-host proto kernel scope link src 10.0.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50</pre>
Let's decode this:

* <code>default via 192.168.1.1 dev eth0</code>: For any destination not matched by more specific routes, forward packets to the gateway at 192.168.1.1 through interface eth0. This is called the "default route" or "default gateway."
* <code>10.0.0.0/24 dev v-host</code>: For destinations in 10.0.0.0/24, send directly out v-host (no gateway needed). This route was automatically created when we assigned 10.0.0.1/24 to v-host.
* <code>192.168.1.0/24 dev eth0</code>: Local network, send directly out eth0.


===== The Default Route =====

The default route (destination <code>0.0.0.0/0</code> or shown as <code>default</code>) is the "route of last resort." It's a catch-all that matches any destination not covered by more specific routes. Without a default route, the kernel can only reach directly connected networks.

The gateway specified in the default route must itself be reachable via a local network. You can't set a gateway to an IP address that the kernel doesn't know how to reach.

How Routing Decisions Work

When sending a packet to destination IP D:

# The kernel searches the routing table for the most specific match (longest prefix match)
# If a match is found, use that route's interface and gateway
# If no match is found and no default route exists, return "Network is unreachable" error

Example: Routing to 8.8.8.8

* Check local routes: Does 8.8.8.8 match 10.0.0.0/24? No. Does it match 192.168.1.0/24? No.
* Check default route: Yes, <code>default</code> matches everything
* Use the default route: Send packet to gateway 192.168.1.1 via eth0


===== Network Address Translation (NAT) =====

Private IP addresses (like 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are not routable on the public internet. If the client (10.0.0.2) wants to reach Google (8.8.8.8), it faces a problem: Google's servers can't send replies back to 10.0.0.2 because that address is private and potentially used by millions of devices worldwide.

The solution is NAT (Network Address Translation), specifically a technique called "masquerading":

# The client sends a packet to 8.8.8.8 with source IP 10.0.0.2
# The packet reaches the host (acting as a router/gateway)
# The host '''rewrites''' the source IP from 10.0.0.2 to its own public IP (e.g., 203.0.113.5)
# The host forwards the packet to the internet
# Google replies to 203.0.113.5
# The host receives the reply, recognizes it belongs to the client's connection, rewrites the destination IP back to 10.0.0.2, and forwards it to the client

This source IP rewriting is called "masquerading" because the host "masks" the private IP behind its own public IP. The host maintains a connection table to track which internal client made which request.


===== IP Forwarding =====

For the host to act as a router, the kernel must be configured to forward packets between interfaces. By default, Linux does not forward (for security reasons). We enable it with:

<syntaxhighlight lang="bash">sudo sysctl -w net.ipv4.ip_forward=1</syntaxhighlight>
This setting tells the kernel: "If a packet arrives on one interface and is destined for an address reachable via another interface, forward it."


==== Practice: Enabling Internet Access ====


===== Step 1: The Problem - No Route =====

From the client namespace, try to ping Google's DNS server:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 2 8.8.8.8</syntaxhighlight>
Result: <code>connect: Network is unreachable</code>

Why? Let's check the client's routing table:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route show</syntaxhighlight>
You should see only:

<pre>10.0.0.0/24 dev v-client proto kernel scope link src 10.0.0.2</pre>
This means the client knows how to reach 10.0.0.0/24, but it has no idea how to reach 8.8.8.8. There's no default route.


===== Step 2: Add a Default Route =====

Tell the client to use the host (10.0.0.1) as its default gateway:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route add default via 10.0.0.1</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route show</syntaxhighlight>
You should now see:

<pre>default via 10.0.0.1 dev v-client
10.0.0.0/24 dev v-client proto kernel scope link src 10.0.0.2</pre>
This tells the kernel: "For any destination I don't have a specific route for, send it to 10.0.0.1."


===== Step 3: The Problem - No Forwarding =====

Try pinging again:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 2 8.8.8.8</syntaxhighlight>
It might still fail or timeout. Why? Even though the client sends packets to the host, the host might not be forwarding them. Let's enable IP forwarding on the host:

<syntaxhighlight lang="bash">sudo sysctl -w net.ipv4.ip_forward=1</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">sysctl net.ipv4.ip_forward</syntaxhighlight>
Should show: <code>net.ipv4.ip_forward = 1</code>


===== Step 4: The Problem - No NAT =====

Try pinging again:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 2 8.8.8.8</syntaxhighlight>
It still might not work. The packets are being forwarded, but they have source IP 10.0.0.2. The internet routers don't know how to route replies back to private IP addresses. We need NAT.


===== Step 5: Configure NAT (Masquerade) =====

We'll use nftables to configure NAT. First, identify your internet-connected interface (replace <code>eth0</code> if yours is different):

<syntaxhighlight lang="bash">ip route show default</syntaxhighlight>
Look for <code>default via X.X.X.X dev INTERFACE</code>. Note the interface name (e.g., <code>eth0</code>).

Now configure NAT to masquerade traffic from the 10.0.0.0/24 subnet going out your internet interface:

<syntaxhighlight lang="bash">sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; }
sudo nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "eth0" masquerade</syntaxhighlight>
'''Important''': Replace <code>"eth0"</code> with your actual internet interface name.

The nftables interface is a complex and powerful kernel tool for firewall and NAT managment. Understanding exactly how this works is beyond the scope of this lab. For now, use the commands aboce "as-is".

Verify the rule:

<syntaxhighlight lang="bash">sudo nft list ruleset</syntaxhighlight>

===== Step 6: Success! =====

Now try pinging from the client:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 3 8.8.8.8</syntaxhighlight>
Success! The client can now reach the internet. You can also try:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ping -c 3 google.com</syntaxhighlight>
This tests DNS resolution as well. If this works, your client has full internet connectivity.

What Just Happened?

When the client pings 8.8.8.8:

# Client kernel checks routing table, finds default route via 10.0.0.1
# Client sends packet to 10.0.0.1 (the host)
# Host receives packet, checks if IP forwarding is enabled (yes)
# Host checks its routing table for 8.8.8.8, finds default route via internet gateway
# Host's nftables NAT rule rewrites source IP from 10.0.0.2 to host's public IP
# Host forwards packet to internet gateway
# Packet reaches 8.8.8.8, reply comes back to host's public IP
# Host's NAT table recognizes this is a reply to client's connection
# Host rewrites destination IP from host's public IP back to 10.0.0.2
# Host forwards reply to client via v-host interface

All of this happens transparently at wire speed, managed by the kernel.


==== Deliverable D ====

After following exercise 4, provide the output of:

<syntaxhighlight lang="bash">sudo ip netns exec client_ns ip route show
sudo ip netns exec client_ns ping -c 3 8.8.8.8</syntaxhighlight>

=== Exercise 5: Virtual Switches (Linux Bridge) ===


==== Theory: Hub-and-Spoke vs. Switched Networks ====

So far, we've created a simple point-to-point connection using a veth pair. This works for connecting two devices, but what if we want to connect multiple devices? We could create veth pairs between every pair of devices, but that's not scalable. A three-device network would need 3 pairs, a four-device network would need 6 pairs, and so on.

The traditional solution is a network switch.


===== Physical vs. Virtual Switches =====

A physical Ethernet switch is a hardware device with multiple ports. When it receives a frame on one port, it examines the destination MAC address and forwards the frame only to the port where that MAC address is located. The switch learns MAC address locations by observing source addresses on incoming frames.

A Linux bridge is a software implementation of a network switch. It's a virtual interface that you can "plug" other interfaces into. The bridge learns MAC addresses and forwards frames intelligently, just like a physical switch.

Key characteristics of a bridge:

* Operates at the network level (MAC addresses)
* Supports multiple connected interfaces
* Learns MAC addresses dynamically
* Provides broadcast domain for protocols like ARP
* Transparent to IP protocols

Creating a Switched Topology

In this exercise, we'll recreate our network with a proper switched architecture:

<pre> [Host]
|
| v-host (connected to br-lab)
|
[br-lab] (bridge/switch)
|
+--- v-red-br ~~~ v-red-ns ----> [Red NS]
|
+--- v-blue-br ~~~ v-blue-ns ---> [Blue NS]</pre>
The bridge (<code>br-lab</code>) acts as a switch. The host, red namespace, and blue namespace are all "plugged into" different ports of this virtual switch.

Why This Matters

This architecture mirrors real networks:

* Home networks: Your home router has a built-in switch connecting your devices
* Data centers: Switches connect servers to network backbones
* Cloud environments: Virtual switches (like Open vSwitch) connect containers and VMs
* Container orchestration: Docker and Kubernetes use Linux bridges for container networking

Understanding bridges is essential for working with modern virtualization and containerization technologies.


==== Practice: Building a Switched Network ====


===== Step 1: Clean Up Previous Configuration =====

Remove the old point-to-point setup:

<syntaxhighlight lang="bash">sudo ip netns delete client_ns
sudo ip link delete v-host</syntaxhighlight>
The veth pair is automatically cleaned up when we delete v-host (since they're paired).

Verify:

<syntaxhighlight lang="bash">ip netns list
ip link show | grep v-</syntaxhighlight>
Both should show no results.


===== Step 2: Create the Bridge (Virtual Switch) =====

Create a Linux bridge named <code>br-lab</code>:

<syntaxhighlight lang="bash">sudo ip link add name br-lab type bridge</syntaxhighlight>
Bring it up:

<syntaxhighlight lang="bash">sudo ip link set br-lab up</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">ip link show br-lab</syntaxhighlight>
You should see a new interface of type <code>bridge</code> in state UP.


===== Step 3: Create Network Namespaces for Two Clients =====

Create namespaces for "red" and "blue" clients:

<syntaxhighlight lang="bash">sudo ip netns add red
sudo ip netns add blue</syntaxhighlight>
Verify:

<syntaxhighlight lang="bash">ip netns list</syntaxhighlight>

===== Step 4: Create and Connect Red Client =====

Create a veth pair for the red client:

<syntaxhighlight lang="bash">sudo ip link add v-red-br type veth peer name v-red-ns</syntaxhighlight>
Connect one end (<code>v-red-br</code>) to the bridge:

<syntaxhighlight lang="bash">sudo ip link set v-red-br master br-lab</syntaxhighlight>
This "plugs" v-red-br into the switch. The <code>master</code> keyword means "this interface is now a port of the bridge."

Move the other end into the red namespace:

<syntaxhighlight lang="bash">sudo ip link set v-red-ns netns red</syntaxhighlight>
Bring up the bridge-side interface:

<syntaxhighlight lang="bash">sudo ip link set v-red-br up</syntaxhighlight>
Assign IP to red client and bring it up:

<syntaxhighlight lang="bash">sudo ip netns exec red ip addr add 10.0.0.2/24 dev v-red-ns
sudo ip netns exec red ip link set v-red-ns up
sudo ip netns exec red ip link set lo up</syntaxhighlight>

===== Step 5: Create and Connect Blue Client =====

Repeat the same process for blue:

<syntaxhighlight lang="bash">sudo ip link add v-blue-br type veth peer name v-blue-ns
sudo ip link set v-blue-br master br-lab
sudo ip link set v-blue-ns netns blue
sudo ip link set v-blue-br up
sudo ip netns exec blue ip addr add 10.0.0.3/24 dev v-blue-ns
sudo ip netns exec blue ip link set v-blue-ns up
sudo ip netns exec blue ip link set lo up</syntaxhighlight>

===== Step 6: Configure the Host Interface =====

The host also needs to be connected to the switch. We'll assign an IP address directly to the bridge interface:

<syntaxhighlight lang="bash">sudo ip addr add 10.0.0.1/24 dev br-lab</syntaxhighlight>
Why does this work? A bridge can have an IP address, making the host itself a participant on the switched network. This is simpler than creating another veth pair.


===== Step 7: Verify the Topology =====

Check bridge status:

<syntaxhighlight lang="bash">ip link show master br-lab</syntaxhighlight>
This shows all interfaces connected to the bridge. You should see <code>v-red-br</code> and <code>v-blue-br</code>.

Or use the bridge utility:

<syntaxhighlight lang="bash">bridge link show</syntaxhighlight>
Check IP addresses:

<syntaxhighlight lang="bash">ip addr show br-lab
sudo ip netns exec red ip addr show v-red-ns
sudo ip netns exec blue ip addr show v-blue-ns</syntaxhighlight>

===== Step 8: Test Connectivity =====

Red to Blue (peer-to-peer):

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 3 10.0.0.3</syntaxhighlight>
Blue to Red:

<syntaxhighlight lang="bash">sudo ip netns exec blue ping -c 3 10.0.0.2</syntaxhighlight>
Red to Host:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 3 10.0.0.1</syntaxhighlight>
Blue to Host:

<syntaxhighlight lang="bash">sudo ip netns exec blue ping -c 3 10.0.0.1</syntaxhighlight>
All of these should succeed. The bridge is forwarding frames between all three participants.

Host to Red:

<syntaxhighlight lang="bash">ping -c 3 10.0.0.2</syntaxhighlight>
Host to Blue:

<syntaxhighlight lang="bash">ping -c 3 10.0.0.3</syntaxhighlight>

===== Step 9: Enable Internet Access for Clients =====

Add default routes for both clients:

<syntaxhighlight lang="bash">sudo ip netns exec red ip route add default via 10.0.0.1
sudo ip netns exec blue ip route add default via 10.0.0.1</syntaxhighlight>
Verify IP forwarding is still enabled (should be from Exercise 4):

<syntaxhighlight lang="bash">sysctl net.ipv4.ip_forward</syntaxhighlight>
If not set to 1, enable it:

<syntaxhighlight lang="bash">sudo sysctl -w net.ipv4.ip_forward=1</syntaxhighlight>
Ensure NAT is still configured (should be from Exercise 4):

<syntaxhighlight lang="bash">sudo nft list ruleset | grep masquerade</syntaxhighlight>
If not present, add it again (replace <code>eth0</code> with your internet interface):

<syntaxhighlight lang="bash">sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; }
sudo nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "eth0" masquerade</syntaxhighlight>
Test internet access:

<syntaxhighlight lang="bash">sudo ip netns exec red ping -c 3 8.8.8.8
sudo ip netns exec blue ping -c 3 8.8.8.8</syntaxhighlight>
Both clients can now reach the internet through the host, which acts as both a switch (via the bridge) and a router (via IP forwarding and NAT).

Understanding the Data Flow

When Red (10.0.0.2) pings Blue (10.0.0.3):

# Red's kernel sees 10.0.0.3 is in the local subnet, sends ARP request
# ARP request goes out v-red-ns, through the veth pair to v-red-br
# v-red-br is connected to br-lab (the switch)
# br-lab broadcasts the ARP request to all connected interfaces (v-blue-br and itself)
# Blue receives ARP request via v-blue-ns, replies with its MAC
# br-lab learns Blue's MAC address is on port v-blue-br
# Subsequent packets from Red to Blue are forwarded directly to v-blue-br (no broadcast)
# The bridge maintains a MAC address table, just like a physical switch

When Red (10.0.0.2) pings Google (8.8.8.8):

# Red's kernel sees 8.8.8.8 is not in the local subnet, consults routing table
# Default route says to send to gateway 10.0.0.1 (the host)
# Red uses ARP to find MAC of 10.0.0.1
# Packet goes through veth pair to br-lab
# br-lab forwards to its own IP (10.0.0.1 is assigned to br-lab)
# Host kernel receives packet, sees it's destined for 8.8.8.8
# IP forwarding is enabled, so host checks routing table
# Host finds default route via internet gateway
# NAT rule rewrites source IP from 10.0.0.2 to host's public IP
# Packet forwarded to internet


=== Scripting Challenges ===

These challenges test your ability to automate network configuration and extract useful diagnostic information from the kernel's network subsystem.


==== Challenge 1: Automated Network Builder ====

Write a bash script <code>lab7_builder.sh</code> that automatically constructs the Red/Blue/Bridge topology from Exercise 5, assigns IP addresses, enables routing and NAT, and provides cleanup functionality.

Requirements:

# '''Script Name ''': <code>lab7_builder.sh</code>
# '''Shebang and Best Practices''':
#* Start with <code>#!/bin/bash</code>
#* Use <code>set -euo pipefail</code> for error handling
# '''Arguments''':
#* <code>start</code>: Create and configure the network
#* <code>stop</code>: Clean up all created resources
# '''Start Operation Must''':
#* Create bridge <code>br-lab</code>
#* Create namespaces <code>red</code> and <code>blue</code>
#* Create veth pairs and connect them to the bridge and namespaces
#* Assign IP addresses:
#** Host (br-lab): 10.0.0.1/24
#** Red: 10.0.0.2/24
#** Blue: 10.0.0.3/24
#* Bring all interfaces UP
#* Add default routes for both clients pointing to 10.0.0.1
#* Enable IP forwarding
#* Configure NAT/masquerade for 10.0.0.0/24 traffic going out the default internet interface
#* Print a success message: "Network topology created successfully"
# '''Stop Operation Must''':
#* Delete namespaces (this automatically removes interfaces inside them)
#* Delete bridge
#* Flush nftables nat table
#* Disable IP forwarding (set back to 0)
#* Print a success message: "Network topology cleaned up successfully"

Testing:

<syntaxhighlight lang="bash">chmod +x ./lab7_builder.sh
sudo ./lab7_builder.sh start
sudo ip netns exec red ping -c 2 10.0.0.3
sudo ip netns exec red ping -c 2 8.8.8.8
sudo ./lab7_builder.sh stop</syntaxhighlight>

===== Deliverable Challenge 1: =====

* Complete script source code with comments
* Output of running the script with <code>start</code> argument
* Output of connectivity tests (red to blue, red to internet)
* Output of running the script with <code>stop</code> argument


==== Challenge 2: Namespace Inspector ====

Write a bash script <code>lab7_inspect.sh</code> that takes a namespace name as an argument and displays diagnostic information about that namespace's network configuration.

Requirements:

<ol style="list-style-type: decimal;">
<li>'''Script Name''': <code>lab7_inspect.sh</code></li>
<li>'''Shebang and Best Practices''':
<ul>
<li>Start with <code>#!/bin/bash</code></li>
<li>Use <code>set -euo pipefail</code></li>
<li>Use functions</li>
<li>Comment your code</li></ul>
</li>
<li>'''Arguments''':
<ul>
<li>Takes exactly one argument: the namespace name</li>
<li>If no argument or more than one argument, print usage and exit with error</li></ul>
</li>
<li>'''Output Format''' (exactly as shown):
<pre>=== Network Inspection for Namespace: <ns_name> ===

[Interfaces]
<output of ip link show>

[IP Addresses]
<output of ip addr show>

[Routes]
<output of ip route show>

[Default Gateway]
<extract and show only the default gateway IP, or "None" if not configured>

[Neighbors (ARP Cache)]
<output of ip neigh show></pre></li>
<li>'''Functionality''':
<ul>
<li>Check if namespace exists before attempting to inspect</li>
<li>All commands should run inside the specified namespace</li>
<li>Extract the default gateway IP from the routing table (hint: grep for "default" and extract the IP after "via")</li></ul>
</li></ol>

Testing (after running Challenge 1's start command):

<syntaxhighlight lang="bash">chmod +x ./lab7_inspect.sh
sudo ./lab7_inspect.sh red
sudo ./lab7_inspect.sh blue</syntaxhighlight>

====== Deliverable Challenge 2: ======

* Complete script source code with comments
* Output of running the script for the <code>red</code> namespace (after pinging a few addresses to populate ARP cache)


== Reference: Network Command Quick Guide ==

This section provides a quick reference for the commands introduced in this lab.


=== Interface Management (ip link) ===

<syntaxhighlight lang="bash"># List all interfaces
ip link show

# Create veth pair
sudo ip link add dev <name1> type veth peer name <name2>

# Move interface to namespace
sudo ip link set <interface> netns <namespace>

# Bring interface up/down
sudo ip link set <interface> up
sudo ip link set <interface> down

# Delete interface
sudo ip link delete <interface>

# Create bridge
sudo ip link add name <bridge> type bridge

# Connect interface to bridge
sudo ip link set <interface> master <bridge></syntaxhighlight>

=== Address Management (ip addr) ===

<syntaxhighlight lang="bash"># Show addresses
ip addr show
ip addr show <interface>

# Add address
sudo ip addr add <ip>/<prefix> dev <interface>
# Example: sudo ip addr add 10.0.0.1/24 dev eth0

# Remove address
sudo ip addr del <ip>/<prefix> dev <interface>

# Flush all addresses from interface
sudo ip addr flush dev <interface></syntaxhighlight>

=== Routing Management (ip route) ===

<syntaxhighlight lang="bash"># Show routing table
ip route show

# Add route
sudo ip route add <network>/<prefix> via <gateway>
# Example: sudo ip route add 192.168.2.0/24 via 192.168.1.1

# Add default route
sudo ip route add default via <gateway>
# Example: sudo ip route add default via 10.0.0.1

# Delete route
sudo ip route del <network>/<prefix>
sudo ip route del default

# Flush routing table
sudo ip route flush table main</syntaxhighlight>

=== Neighbor Management (ip neigh) ===

<syntaxhighlight lang="bash"># Show ARP cache
ip neigh show

# Flush ARP cache
sudo ip neigh flush all

# Add static ARP entry
sudo ip neigh add <ip> lladdr <mac> dev <interface>

# Delete ARP entry
sudo ip neigh del <ip> dev <interface></syntaxhighlight>

=== Namespace Management (ip netns) ===

<syntaxhighlight lang="bash"># List namespaces
ip netns list

# Create namespace
sudo ip netns add <name>

# Delete namespace
sudo ip netns delete <name>

# Execute command in namespace
sudo ip netns exec <name> <command>
# Example: sudo ip netns exec red ping 10.0.0.1

# Get shell in namespace
sudo ip netns exec <name> bash</syntaxhighlight>

=== Bridge Management ===

<syntaxhighlight lang="bash"># Show bridge details
bridge link show
bridge fdb show # Show MAC address table

# Show which interfaces are part of a bridge
ip link show master <bridge></syntaxhighlight>

=== IP Forwarding ===

<syntaxhighlight lang="bash"># Check status
sysctl net.ipv4.ip_forward

# Enable (temporary)
sudo sysctl -w net.ipv4.ip_forward=1

# Disable
sudo sysctl -w net.ipv4.ip_forward=0

# Enable permanently (edit /etc/sysctl.conf)
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf</syntaxhighlight>

=== NAT with nftables ===

<syntaxhighlight lang="bash"># List current ruleset
sudo nft list ruleset

# Create NAT table and rules
sudo nft add table ip nat
sudo nft add chain ip nat postrouting { type nat hook postrouting priority srcnat \; }
sudo nft add rule ip nat postrouting ip saddr 10.0.0.0/24 oifname "eth0" masquerade

# Delete NAT table
sudo nft delete table ip nat

# Flush ruleset
sudo nft flush ruleset</syntaxhighlight>

=== Diagnostic Tools ===

<syntaxhighlight lang="bash"># Test connectivity
ping -c 3 <ip>

# Trace route
traceroute <ip>

# Show listening sockets
ss -tuln

# Monitor traffic
sudo tcpdump -i <interface>
sudo tcpdump -i <interface> -n arp # Show only ARP traffic
sudo tcpdump -i <interface> -n icmp # Show only ping traffic

# Show interface statistics
ip -s link show <interface></syntaxhighlight>

== Common Network Topology Patterns ==


=== Point-to-Point Connection ===

<pre>[Host] <---veth pair---> [Namespace]</pre>
Use case: Simple container isolation, testing


=== Switched Network ===

<pre> [Bridge]
|
+-------+-------+
| | |
[Host] [NS1] [NS2]</pre>
Use case: Multiple containers/VMs on same network


=== Routed Network ===

<pre>[Internet] <---> [Host/Router] <---> [Bridge] <---> [Containers]
(NAT)</pre>
Use case: Containers with internet access


== Summary Table: Network Components ==

{| class="wikitable"
|-
! Component
! Purpose
! Layer
! Key Commands
|-
| veth pair
| Virtual cable connecting two interfaces
| L2
| <code>ip link add type veth</code>
|-
| bridge
| Virtual switch
| L2
| <code>ip link add type bridge</code>
|-
| IP address
| Device identity and subnet membership
| L3
| <code>ip addr add</code>
|-
| Route
| Path determination
| L3
| <code>ip route add</code>
|-
| ARP/Neighbor
| IP-to-MAC mapping
| L2/L3
| <code>ip neigh show</code>
|-
| NAT
| Private-to-public IP translation
| L3
| <code>nft add rule masquerade</code>
|-
| Namespace
| Isolated network stack
| All
| <code>ip netns add</code>
|}


== Deliverables and Assessment ==

Submit a single PDF document containing:

The deliverables A-D and solutions to the challanges 1 and 2.


== For further study: ==

'''Advanced Topics''':

* VLANs and 802.1Q tagging
* Open vSwitch (OVS) for advanced switching
* Network policies and firewalling with nftables
* Quality of Service (QoS) and traffic shaping
* IPv6 configuration and dual-stack networking
* VPN setup with WireGuard or OpenVPN

'''Container Networking''':

* Docker networking modes (bridge, host, overlay)
* Kubernetes networking model and CNI plugins
* Service meshes (Istio, Linkerd)

'''Performance and Monitoring''':

* Network performance testing with iperf
* Packet capture and analysis with Wireshark
* Continuous monitoring with Prometheus and Grafana

'''Security''':

* Network segmentation and isolation
* Firewall rule design
* Intrusion detection systems
* Zero-trust networking


=== Relevant Manual Pages: ===

<syntaxhighlight lang="bash">man 8 ip # iproute2 command reference
man 8 ip-link # Interface management
man 8 ip-address # Address management
man 8 ip-route # Routing management
man 8 ip-netns # Namespace management
man 8 bridge # Bridge management
man 7 netdevice # Network device overview
man 7 arp # ARP protocol
man 5 nft # nftables syntax
man 8 tcpdump # Packet capture</syntaxhighlight>

=== Online Resources: ===

* [https://lartc.org/ Linux Advanced Routing & Traffic Control HOWTO]
* [https://wiki.linuxfoundation.org/networking/iproute2 iproute2 documentation]
* [https://www.kernel.org/doc/html/latest/networking/ The Linux Kernel Networking Stack]
* [https://wiki.nftables.org/ nftables Wiki]

Operating Systems

2025-11-21T14:45:44Z

Vserbu:

OS Lab 6 - Inter Process Communication

2025-11-14T15:06:48Z

Vserbu: /* Deliverables and Assessment */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how the kernel provides IPC mechanisms and how bash exposes them to scripts.
* Use environment variables and <code>export</code> to pass configuration from parent processes to children.
* Construct pipelines with anonymous pipes to connect process standard streams.
* Create and use named pipes (FIFOs) for communication between unrelated processes.
* Send signals to processes and handle them with <code>trap</code> for asynchronous event-driven scripting.
* Demonstrate basic socket communication using existing utilities for network IPC.


== Introduction ==

In Lab 5, we explored bash scripting as a way to automate tasks by writing programs that the shell interprets. We learned how processes execute scripts, how to control flow with conditionals and loops, and how to structure code with functions. However, all of our scripts operated in isolation. Each script was a single process (or spawned child processes) that performed its task independently.

Real-world systems require processes to cooperate. A web server must communicate with a database. A shell pipeline connects the output of one program to the input of another. A service must respond to signals sent by the init system. This lab explores the kernel-provided mechanisms that enable processes to exchange data and coordinate their actions. We focus on five fundamental IPC mechanisms, all accessible from bash: environment variables, pipes, named pipes, signals, and sockets.

Understanding IPC is essential for system administration and software development. These mechanisms form the foundation of everything from command pipelines to distributed systems.


== Prerequisites ==


=== System Requirements ===

A running instance of the course-provided Linux virtual machine with SSH or direct terminal access.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y caddy socat</syntaxhighlight>
* <code>caddy</code>: A modern HTTP server with automatic HTTPS. We use it to demonstrate socket communication.
* <code>socat</code>: A versatile networking tool that can work with Unix domain sockets.


=== Knowledge Prerequisites ===

You should be familiar with: - Process concepts from Lab 3 (PIDs, process hierarchy, file descriptors) - File permissions from Lab 4 (execute bit, ownership) - Bash scripting fundamentals from Lab 5 (shebangs, builtins, variables, quoting, exit status, redirection, loops, functions)


== Inter-Process Communication ==


=== What is IPC? ===

By default, processes are isolated from one another. Each process has its own memory space, file descriptor table, and execution context. This isolation provides security and stability, but it creates a problem: how can processes cooperate to accomplish complex tasks?

Inter-Process Communication (IPC) refers to the kernel-provided mechanisms that allow processes to exchange data and synchronize their actions. The kernel acts as an intermediary, providing channels, buffers, and signaling primitives that processes can use to communicate safely without violating isolation boundaries.

In this lab, we examine five IPC mechanisms arranged roughly by complexity:

# '''Environment Variables''': The simplest form of IPC. A parent process passes key-value configuration to its children via inherited environment variables. Communication is unidirectional (parent → child) and occurs only at process creation.
# '''Pipes''': The kernel creates a buffer connecting one process’s standard output to another’s standard input. Data flows in one direction through the pipe. Anonymous pipes exist only while the processes using them are running.
# '''Named Pipes (FIFOs)''': Like anonymous pipes, but visible in the filesystem. This persistence allows unrelated processes to connect to the same pipe by opening a file path.
# '''Signals''': Asynchronous notifications sent from one process to another (or from the kernel to a process). Signals interrupt the receiving process, which can catch and handle them or allow default behavior (often termination).
# '''Sockets''': Bidirectional communication channels that work across network boundaries or locally via Unix domain sockets. Multiple processes can connect to the same socket, enabling one-to-many communication patterns.

Each mechanism solves different problems and has different trade-offs in terms of complexity, performance, and flexibility.


=== Environment Variables and <code>export</code> ===


==== The Kernel’s Role ====

When a process forks, the child inherits a copy of the parent’s environment: a set of key-value string pairs maintained by the kernel for each process. The child can read these values and modify its own copy, but changes do not propagate back to the parent or to other processes. This inheritance mechanism provides a simple, unidirectional channel for passing configuration from parent to child.

Environment variables are not limited to shell scripts. Every process has an environment. When you run any program, it receives the environment from the shell that launched it. Programs written in C access this via the <code>environ</code> global variable or the third parameter to <code>main()</code>. Python uses <code>os.environ</code>. The environment is a universal convention for passing configuration.


==== Bash’s Role: <code>export</code> and <code>env</code> ====

In bash, variables are local to the shell process by default. When you set <code>name=value</code>, that variable exists in the shell’s memory but is '''not''' passed to child processes. The <code>export</code> builtin marks a variable for inclusion in the environment of future child processes:

<syntaxhighlight lang="bash">myvar="hello"
export myvar</syntaxhighlight>
Or, more concisely:

<syntaxhighlight lang="bash">export myvar="hello"</syntaxhighlight>
Once exported, all child processes started by this shell (scripts, programs, or subshells) will inherit <code>myvar</code> in their environment. To see the current environment, use the <code>env</code> command (or <code>printenv</code>), which prints all exported variables.

You can also set environment variables for a single command without affecting the shell:

<syntaxhighlight lang="bash">DEBUG=1 ./myscript.sh</syntaxhighlight>
This syntax sets <code>DEBUG=1</code> in the environment of <code>myscript.sh</code> only, without exporting it in the parent shell.

Common environment variables you’ve already been using include <code>PATH</code> (where bash searches for commands), <code>HOME</code> (your home directory), <code>USER</code> (your username), and <code>SHELL</code> (your login shell). These are all set by the login process and inherited by every subsequent process in your session.


==== When to Use Environment Variables ====

Environment variables are appropriate for: - Configuration that should be inherited by all child processes (e.g., locale settings, proxy configuration) - Passing secrets or credentials to programs without embedding them in command-line arguments (which are visible via <code>ps</code>) - Controlling program behavior via well-known variables like <code>PATH</code>, <code>LD_LIBRARY_PATH</code>, or <code>TZ</code>

They are '''not''' suitable for: - Runtime communication between already-running processes (use pipes, sockets, or signals) - Large amounts of data (environment is limited in size, typically a few megabytes) - Bi-directional communication (child changes don’t affect parent)


=== Pipes ===


==== The Kernel’s Pipe Mechanism ====

A pipe is a one-way data channel maintained in kernel memory. When you create a pipe, the kernel allocates a buffer (typically 64 KB on Linux) and returns two file descriptors: one for writing and one for reading. Data written to the write end is buffered by the kernel and can be read from the read end in FIFO (first-in, first-out) order.

Pipes are anonymous: they have no name in the filesystem. They exist only as long as at least one process holds a file descriptor to them. When all processes close their references to a pipe, the kernel deallocates it.

The key insight from Lab 3: a pipeline like <code>cat file.txt | grep "error" | wc -l</code> creates multiple processes (all in the same process group) connected by pipes. The kernel sets up the file descriptors so that <code>cat</code>’s stdout is connected to <code>grep</code>’s stdin, and <code>grep</code>’s stdout is connected to <code>wc</code>’s stdin. The processes run concurrently, with data flowing through kernel buffers as it’s produced and consumed.


==== Bash’s Pipe Operator ====

Bash creates pipes using the <code>|</code> operator. The syntax is simple:

<syntaxhighlight lang="bash">command1 | command2</syntaxhighlight>
This creates a pipe and starts two processes. Bash configures <code>command1</code>’s stdout (FD 1) to point to the pipe’s write end and <code>command2</code>’s stdin (FD 0) to point to the pipe’s read end. The commands execute concurrently.

Longer pipelines work the same way:

<syntaxhighlight lang="bash">cat data.txt | sort | uniq | wc -l</syntaxhighlight>
This creates three pipes connecting four processes. Data flows left-to-right through kernel buffers.


==== Pipes in Scripts ====

You can use pipes inside scripts just as you would interactively:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

# Count unique IP addresses in an access log
cat /var/log/access.log | cut -d' ' -f1 | sort | uniq | wc -l</syntaxhighlight>
Pipes are particularly powerful when combined with bash’s process substitution feature <code><(command)</code>, but that’s beyond the scope of this introductory lab.


==== When to Use Pipes ====

Pipes are ideal for: - Connecting the output of one program to the input of another in a linear processing chain - Streaming data processing where data is generated and consumed incrementally - Quick, one-off data transformations at the command line

They are '''not''' suitable for: - Bi-directional communication (data flows one way only) - Communication between unrelated processes that weren’t started in a pipeline - Persistent communication (pipe disappears when processes exit)


=== Named Pipes (FIFOs) ===


==== The Kernel’s FIFO Mechanism ====

A named pipe, or FIFO (First-In, First-Out), is a pipe with a name in the filesystem. Unlike anonymous pipes, FIFOs persist as filesystem entries (though the data buffer is still in kernel memory). Any process with appropriate permissions can open the FIFO by its path, allowing unrelated processes to communicate.

When a process opens a FIFO for reading, it blocks until another process opens the same FIFO for writing (and vice versa). Once both ends are open, data flows through the kernel buffer just like an anonymous pipe. When all processes close their connections, the FIFO remains as a filesystem entry but the kernel buffer is deallocated.

You can identify a FIFO in <code>ls -l</code> output by the leading <code>p</code> in the permission string:

<pre>prw-r--r-- 1 user user 0 Nov 6 10:00 myfifo</pre>

==== Creating FIFOs with <code>mkfifo</code> ====

The <code>mkfifo</code> command creates a named pipe:

<syntaxhighlight lang="bash">mkfifo /tmp/myfifo</syntaxhighlight>
Now two unrelated processes can communicate by opening this file. One writes to it:

<syntaxhighlight lang="bash">echo "Hello from writer" > /tmp/myfifo</syntaxhighlight>
This command will block until a reader appears. In another terminal (or in the background), a reader can consume the data:

<syntaxhighlight lang="bash">cat < /tmp/myfifo</syntaxhighlight>
When the reader connects, the writer unblocks, the message flows through the kernel buffer, and both commands complete.


==== When to Use Named Pipes ====

Named pipes are useful for: - Communication between unrelated processes that start at different times - Producer-consumer patterns where one process generates data and another processes it - Simple IPC without needing network sockets or shared files

They are '''not''' suitable for: - Multiple simultaneous readers or writers (FIFO semantics become unpredictable) - Persistent data storage (data is lost when all processes disconnect) - Bi-directional communication (like anonymous pipes, FIFOs are one-way)


=== Signals and <code>trap</code> ===


==== The Kernel’s Signal Mechanism ====

A signal is an asynchronous notification sent to a process. Signals can be sent by other processes (via the <code>kill</code> system call) or by the kernel itself in response to events like segmentation faults, keyboard interrupts (Ctrl+C), or child process termination.

When the kernel delivers a signal to a process, it interrupts the process’s normal execution. The process can respond in one of three ways:

# '''Default Action''': Each signal has a default behavior, often terminating the process. For example, <code>SIGTERM</code> (signal 15) gracefully terminates, while <code>SIGKILL</code> (signal 9) forces immediate termination.
# '''Ignore''': The process can choose to ignore certain signals (except <code>SIGKILL</code> and <code>SIGSTOP</code>, which cannot be caught or ignored).
# '''Custom Handler''': The process can register a function (signal handler) to execute when the signal arrives. This allows the process to perform cleanup or take other actions before deciding whether to continue, terminate, or take other action.

Common signals: - <code>SIGINT</code> (2): Sent by Ctrl+C. Default: terminate. - <code>SIGTERM</code> (15): Polite request to terminate. Default: terminate. Most services handle this to perform clean shutdown. - <code>SIGKILL</code> (9): Immediate termination. Cannot be caught or ignored. Used as a last resort. - <code>SIGHUP</code> (1): Historically “hang up” (modem disconnected). Often used to tell daemons to reload configuration. - <code>SIGCHLD</code> (17): Sent to a parent when a child process terminates. - <code>SIGUSR1</code> (10) and <code>SIGUSR2</code> (12): User-defined signals for custom purposes.

Signals are sent by PID:

<syntaxhighlight lang="bash">kill -TERM 1234 # Send SIGTERM to process 1234
kill -9 1234 # Send SIGKILL to process 1234
kill -HUP 1234 # Send SIGHUP to process 1234</syntaxhighlight>
You can also use the <code>%n</code> job notation from Lab 3 to send signals to background jobs.


==== Bash’s <code>trap</code> Builtin ====

The <code>trap</code> builtin allows a bash script to register a handler for incoming signals:

<syntaxhighlight lang="bash">trap 'echo "Caught SIGINT"; exit' INT</syntaxhighlight>
This tells bash: “When SIGINT arrives, execute the command <code>echo "Caught SIGINT"; exit</code>.” The handler can be any bash command or function.

Common pattern for cleanup on exit:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

cleanup() {
echo "Cleaning up temporary files..."
rm -f /tmp/myscript.*
}

trap cleanup EXIT

# Script body
echo "Running..."
sleep 10
echo "Done"

# cleanup() is automatically called on normal exit, Ctrl+C, or errors (with set -e)</syntaxhighlight>
The special signal <code>EXIT</code> isn’t a real signal; it’s a bash pseudo-signal that fires whenever the script exits for any reason.


==== When to Use Signals ====

Signals are appropriate for: - Event-driven scripts that respond to external events - Graceful shutdown and cleanup on termination - Daemon control (reload config with <code>SIGHUP</code>, graceful restart with <code>SIGTERM</code>) - Inter-process coordination where one process needs to notify another of state changes

They are '''not''' suitable for: - Transferring data (signals carry almost no information, just the signal number) - Reliable communication (signals can be lost or delayed) - Complex coordination (race conditions are common)


=== Sockets ===


==== The Kernel’s Socket Mechanism ====

A socket is a bidirectional communication endpoint. Unlike pipes, sockets support two-way data flow. Unlike named pipes, sockets support multiple concurrent connections, making them suitable for client-server architectures.

There are two main types:

# '''Network Sockets''': Use TCP or UDP to communicate over IP networks. These work across machines and are the foundation of the internet.
# '''Unix Domain Sockets''': Use file paths (like named pipes) but support bidirectional communication and connection multiplexing. These work only on the same machine but are faster than network sockets.

When a server process binds to a socket, it listens for incoming connections. Multiple client processes can connect to the same server socket. Each connection is independent, with its own bidirectional channel. This one-to-many pattern distinguishes sockets from pipes and FIFOs.

For network sockets, the server binds to a port number (e.g., port 80 for HTTP). For Unix domain sockets, it binds to a filesystem path (e.g., <code>/tmp/myservice.sock</code>).


==== Socket Communication from Bash ====

While bash doesn’t have native socket support, we can use existing tools to demonstrate socket communication without writing low-level code:

* '''caddy''': A modern web server that can listen on both network and Unix domain sockets
* '''curl''': A command-line HTTP client that supports Unix domain sockets
* '''socat''': A general-purpose networking tool for creating and connecting to various socket types

These tools abstract the complexity of socket programming, allowing us to focus on the conceptual model.


==== When to Use Sockets ====

Sockets are ideal for: - Client-server applications with multiple concurrent clients - Networked communication across machines - Bidirectional data exchange - Services that need to accept connections from many processes

They are '''not''' necessary for: - Simple one-to-one, one-way communication (use pipes instead) - Configuration passing (use environment variables) - Asynchronous notifications (use signals)


== Hands-on Exercises ==


=== Exercise A: Environment Variables and <code>export</code> ===

This exercise demonstrates how environment variables are inherited by child processes but not propagated back to parents.

'''Steps:'''

# Check your current environment. Run <code>env | head -n 10</code> and observe some of the variables already set.
# Create a shell variable without exporting it: <code>myvar="not exported"</code>.
# Start a subshell with <code>bash</code> and try to read <code>myvar</code> with <code>echo "$myvar"</code>. It should be empty. Exit the subshell.
# Back in your original shell, export the variable: <code>export myvar="exported now"</code>.
# Start a subshell again with <code>bash -c 'echo "In child: $myvar"'</code> and verify that <code>myvar</code> is now accessible.
# In a subshell, modify the variable: <code>bash -c 'myvar="changed in child"; echo "Child modified: $myvar"'</code>.
# Print <code>myvar</code> in the parent shell: <code>echo "Parent still has: $myvar"</code>. Observe that the parent’s value is unchanged.
# Demonstrate setting an environment variable for a single command: <code>GREETING="Hello" bash -c 'echo $GREETING'</code>.
# Verify that <code>GREETING</code> is not set in your current shell: <code>echo "GREETING in parent: $GREETING"</code> (should be empty).
# Use <code>env</code> to run a command with a specific environment: <code>env DEBUG=1 bash -c 'echo "DEBUG=$DEBUG"'</code>.

'''Deliverable A:''' Provide the output showing: the subshell cannot see the unexported variable, the subshell can see the exported variable, the parent is unaffected by child changes, and single-command environment variable setting.


=== Exercise B: Pipes in Practice ===

This exercise explores anonymous pipes and how they connect processes.

'''Steps:'''

# Use a simple pipe to count lines: <code>cat /etc/passwd | wc -l</code>. Observe the result.
# Build a longer pipeline to find how many unique shells are in use: <code>cat /etc/passwd | cut -d: -f7 | sort | uniq</code>. Count them manually or pipe to <code>wc -l</code>.
# Demonstrate that processes in a pipeline run concurrently. Run <code>yes | head -n 5</code>. The <code>yes</code> command produces infinite output, but <code>head</code> reads only 5 lines and then exits, causing <code>yes</code> to receive a <code>SIGPIPE</code> and terminate.
# Create a sample log file for analysis:

<syntaxhighlight lang="bash">cat > /tmp/lab6_sample.log <<'EOF'
2024-01-15 10:00:00 INFO Application started
2024-01-15 10:05:23 ERROR Database connection failed
2024-01-15 10:12:45 WARN Connection timeout
2024-01-15 10:15:00 INFO Retry successful
2024-01-15 10:20:00 ERROR Invalid configuration
2024-01-15 10:25:00 WARN Low memory
EOF</syntaxhighlight>
<ol start="5" style="list-style-type: decimal;">
<li>Use a pipeline to count ERROR entries: <code>grep "ERROR" /tmp/lab6_sample.log | wc -l</code>.</li>
<li>Use a pipeline to extract and count unique log levels: <code>cut -d' ' -f3 /tmp/lab6_sample.log | sort | uniq -c</code>.</li>
<li>Combine multiple operations: Find the timestamps of all ERROR entries: <code>grep "ERROR" /tmp/lab6_sample.log | cut -d' ' -f1,2</code>.</li></ol>

'''Deliverable B:''' Provide the output from the <code>/etc/passwd</code> shell analysis, the <code>yes | head -n 5</code> demonstration, and the log file analysis commands showing ERROR count and unique log levels with counts.


=== Exercise C: Named Pipes (FIFOs) ===

This exercise demonstrates persistent named pipes and communication between unrelated processes.

'''Steps:'''

# Create a named pipe: <code>mkfifo /tmp/lab6_fifo</code>.
# Verify it exists and note its type: <code>ls -l /tmp/lab6_fifo</code>. The leading <code>p</code> indicates a FIFO.
# In one terminal, start a reader that will block: <code>cat < /tmp/lab6_fifo</code>. Leave this running.
# In a second terminal, write to the FIFO: <code>echo "Hello via FIFO" > /tmp/lab6_fifo</code>.
# Observe that the reader in the first terminal unblocks, displays the message, and exits.
# Demonstrate that the FIFO persists. List it again: <code>ls -l /tmp/lab6_fifo</code>.
# Test a more complex scenario. In terminal 1: <code>while read line; do echo "Received: $line"; done < /tmp/lab6_fifo</code>.
# In terminal 2, send multiple messages:

<syntaxhighlight lang="bash">echo "Message 1" > /tmp/lab6_fifo
echo "Message 2" > /tmp/lab6_fifo
echo "Message 3" > /tmp/lab6_fifo</syntaxhighlight>
<ol start="9" style="list-style-type: decimal;">
<li>Observe the messages being received. Press Ctrl+C in terminal 1 to stop the reader.</li>
<li>Remove the FIFO: <code>rm /tmp/lab6_fifo</code>.</li></ol>

'''Deliverable C:''' Provide the <code>ls -l</code> output showing the FIFO type, screenshots or output from both terminals showing the message exchange, and a brief explanation of how the FIFO persists between writes.


=== Exercise D: Signals and <code>trap</code> ===

This exercise demonstrates signal handling in bash using interactive commands.

'''Steps:'''

# Start a simple sleep command: <code>sleep 30</code>. Press Ctrl+C to interrupt it. Observe that it terminates immediately.
# Now run a command that ignores SIGINT: <code>trap 'echo "Caught SIGINT, ignoring..."' INT; sleep 30</code>. Press Ctrl+C. The trap catches the signal and the sleep continues.
# Demonstrate cleanup on exit. Run this compound command:

<syntaxhighlight lang="bash">trap 'echo "Cleanup: removing temp file"; rm -f /tmp/lab6_test.txt' EXIT; \
touch /tmp/lab6_test.txt; \
echo "File created. Press Ctrl+C or wait..."; \
sleep 10; \
echo "Normal exit"</syntaxhighlight>
<ol start="4" style="list-style-type: decimal;">
<li>Try both: let it complete normally, then run it again and interrupt with Ctrl+C. Observe cleanup happens both times.</li>
<li>Start a background sleep: <code>sleep 100 &</code>. Note the PID displayed.</li>
<li>Send SIGTERM to it: <code>kill -TERM <pid></code> (replace <code><pid></code> with the actual PID). Verify it terminated: <code>jobs</code>.</li>
<li>Start another background process that will ignore SIGTERM:</li></ol>

<syntaxhighlight lang="bash">(trap 'echo "Caught SIGTERM, staying alive"' TERM; \
while true; do echo "Running..."; sleep 5; done) &</syntaxhighlight>
<ol start="8" style="list-style-type: decimal;">
<li>Note the PID, then send SIGTERM: <code>kill -TERM <pid></code>. Observe the trap message.</li>
<li>Send SIGKILL to force termination: <code>kill -9 <pid></code>. This cannot be caught.</li>
<li>Verify all background jobs are gone: <code>jobs</code>.</li></ol>

'''Deliverable D:''' Provide output showing: the trapped SIGINT message, cleanup on both normal exit and Ctrl+C, the SIGTERM being caught with the trap message, and SIGKILL forcing termination.


=== Exercise E: Socket Communication Basics ===

This exercise provides a brief introduction to socket communication using existing tools.

'''Steps:'''

# Create a simple static site directory: <code>mkdir -p /tmp/lab6_site && echo "<h1>Hello from Caddy</h1>" > /tmp/lab6_site/index.html</code>.
# Start Caddy as a file server listening on a Unix domain socket: <code>caddy file-server --root /tmp/lab6_site --listen unix//tmp/caddy.sock &</code>. Note the PID.
# Wait a moment for Caddy to start. Verify the socket exists: <code>ls -l /tmp/caddy.sock</code>. Note the <code>s</code> type indicating a socket.
# Use <code>curl</code> to make an HTTP request via the Unix domain socket: <code>curl -v --unix-socket /tmp/caddy.sock http://localhost/</code>.
# Observe the response. Note that the communication is bidirectional: you sent an HTTP request, and the server responded with the HTML content.
# (Optional) Open multiple terminals and run <code>curl</code> simultaneously several times. Each request is handled independently, demonstrating the one-to-many capability of sockets.
# Stop Caddy by sending <code>SIGTERM</code>: <code>kill -TERM <caddy_pid></code> or use <code>pkill caddy</code>.
# Clean up: <code>rm -rf /tmp/lab6_site /tmp/caddy.sock</code>.

'''Deliverable E:''' Provide the <code>ls -l</code> output showing the socket file, the <code>curl</code> output demonstrating the request and response (especially the HTTP headers and HTML body), and a brief explanation (2-3 sentences) of how this differs from a named pipe in terms of directionality and connection multiplexing.


== Scripting Challenges ==


=== Challenge 1: Log Aggregator with Named Pipes ===

Write a script <code>/tmp/lab6_log_aggregator.sh</code> that aggregates log messages from multiple sources using named pipes.

'''Requirements:'''

* Create three named pipes: <code>/tmp/log_fifo1</code>, <code>/tmp/log_fifo2</code>, <code>/tmp/log_fifo3</code>.
* Start three background processes that each write timestamped messages to one of the FIFOs (simulating different log sources). Each should write 5 messages at 1-second intervals.
* Implement a main loop that reads from all three FIFOs simultaneously (hint: use <code>select</code> via <code>read</code> with timeout, or use multiple background readers).
* Write all received messages to a combined log file <code>/tmp/aggregated.log</code> with timestamps.
* Trap <code>SIGTERM</code> to clean up: kill background processes, remove FIFOs, and exit gracefully.
* Use: <code>set -euo pipefail</code>, functions, <code>trap</code>, <code>mkfifo</code>, background processes (<code>&</code>), proper cleanup.

'''Test:'''

<syntaxhighlight lang="bash">chmod +x /tmp/lab6_log_aggregator.sh
/tmp/lab6_log_aggregator.sh &
AGG_PID=$!
sleep 10
kill -TERM $AGG_PID
wait
cat /tmp/aggregated.log</syntaxhighlight>
'''Deliverable Challenge 1:''' - Complete script with comments - Contents of <code>/tmp/aggregated.log</code> showing interleaved messages from all three sources - Brief explanation (2-3 sentences) of why named pipes were necessary here instead of anonymous pipes


=== Challenge 2: Graceful Service Controller ===

Write a script <code>/tmp/lab6_service_controller.sh</code> that manages a long-running service and responds to signals.

'''Requirements:'''

* The script acts as a daemon that runs indefinitely, printing a heartbeat message every 5 seconds.
* Accept one optional argument: a “config file” path. If provided, read a setting (e.g., <code>INTERVAL=10</code>) from the file to control the heartbeat interval.
* Trap <code>SIGHUP</code>: Reload the configuration file and adjust the interval dynamically without restarting the script. Print “Configuration reloaded.”
* Trap <code>SIGTERM</code>: Perform graceful shutdown. Print “Shutting down gracefully…”, wait 2 seconds, then exit cleanly.
* Trap <code>SIGUSR1</code>: Export the current status to <code>/tmp/service_status.txt</code> (e.g., uptime, number of heartbeats sent, current interval). Print “Status exported.”
* Trap <code>EXIT</code>: Perform cleanup. Print “Service stopped.”
* Maintain internal state: count the number of heartbeats sent, track start time.
* Use: <code>set -euo pipefail</code>, functions, <code>trap</code> for multiple signals, variables for state, a loop, cleanup handler.

'''Test:'''

<syntaxhighlight lang="bash">echo "INTERVAL=3" > /tmp/service.conf
chmod +x /tmp/lab6_service_controller.sh
/tmp/lab6_service_controller.sh /tmp/service.conf &
SVC_PID=$!
sleep 10
kill -USR1 $SVC_PID # Export status
cat /tmp/service_status.txt
echo "INTERVAL=1" > /tmp/service.conf
kill -HUP $SVC_PID # Reload config
sleep 5
kill -TERM $SVC_PID # Graceful shutdown
wait</syntaxhighlight>
'''Deliverable Challenge 2:''' - Complete script with comments - Output showing heartbeats before and after <code>SIGHUP</code> (with visible interval change) - Contents of <code>/tmp/service_status.txt</code> after <code>SIGUSR1</code> - Output showing graceful shutdown message after <code>SIGTERM</code>


== Reference: Common IPC Patterns ==

Quick reference for IPC mechanisms covered in this lab:

'''Environment Variables:'''

<syntaxhighlight lang="bash"># Export a variable for child processes
export VAR="value"

# Set for one command only
VAR="value" command

# View all environment variables
env
printenv</syntaxhighlight>
'''Anonymous Pipes:'''

<syntaxhighlight lang="bash"># Simple pipeline
command1 | command2

# Multi-stage pipeline
cat file.txt | grep "pattern" | sort | uniq</syntaxhighlight>
'''Named Pipes:'''

<syntaxhighlight lang="bash"># Create a FIFO
mkfifo /path/to/fifo

# Write to FIFO (blocks until reader connects)
echo "data" > /path/to/fifo

# Read from FIFO (blocks until writer connects)
cat < /path/to/fifo

# Remove FIFO
rm /path/to/fifo</syntaxhighlight>
'''Signals:'''

<syntaxhighlight lang="bash"># Send signal by name
kill -TERM <pid>
kill -HUP <pid>

# Send signal by number
kill -15 <pid>

# Force kill (cannot be caught)
kill -9 <pid>

# Trap signals in a script
trap 'echo "Caught signal"' INT TERM
trap cleanup EXIT

# Define cleanup function
cleanup() {
echo "Cleaning up..."
rm -f /tmp/myfiles.*
}</syntaxhighlight>
'''Sockets (using existing tools):'''

<syntaxhighlight lang="bash"># Start a server on Unix domain socket (using socat)
socat UNIX-LISTEN:/tmp/service.sock,fork EXEC:'/usr/bin/myhandler'

# Connect as client (using socat)
echo "request" | socat - UNIX-CONNECT:/tmp/service.sock

# HTTP via Unix socket (using curl)
curl --unix-socket /tmp/service.sock http://localhost/path</syntaxhighlight>

== Common Patterns Table ==

{| class="wikitable"
|-
! Mechanism
! Direction
! Persistence
! Use Case
|-
| Environment Variables
| Parent → Child (one-way)
| Inherited at fork
| Configuration, credentials
|-
| Pipes (<code>\|</code>)
| One-way
| Ephemeral (process lifetime)
| Command chaining, streaming
|-
| Named Pipes (FIFO)
| One-way
| Filesystem entry persists
| Unrelated process communication
|-
| Signals
| One-way (notification)
| Asynchronous event
| Process control, event notification
|-
| Sockets
| Bidirectional
| Filesystem entry persists (Unix domain)
| Client-server, network services
|}


== Deliverables and Assessment ==

Submit a single document (PDF or similar) containing:

'''Exercise Deliverables:'''

* Exercise A: Outputs demonstrating export behavior, parent-child isolation, and single-command environment variables
* Exercise B: Pipeline outputs and complete analysis script
* Exercise C: FIFO creation output, producer/consumer scripts with sample output
* Exercise D: Complete daemon simulation script with signal handling demonstrations
* Exercise E: Socket file listing, curl output with HTTP headers, explanation of socket vs FIFO differences

'''Challenge Deliverables:'''

* Challenge 1: Complete log aggregator script, aggregated log contents, explanation
* Challenge 2: Complete service controller script, outputs demonstrating all signal handlers (SIGHUP reload, SIGUSR1 status export, SIGTERM shutdown)

'''Additional:'''

* Each deliverable should include command outputs (screenshots or text) and brief explanations where requested.
* For scripts, include the complete, commented source code and example execution output.



== Additional Resources ==

This lab covers the fundamental IPC mechanisms accessible from bash. You’ve learned how processes inherit environment variables, communicate via pipes, respond to signals, and use sockets for network communication. These concepts form the foundation for system administration, scripting, and understanding how complex systems coordinate.

For further study:
* Advanced IPC: Shared memory, message queues, semaphores (typically used in C/C++ programs, not bash)
* Network programming: TCP/UDP sockets, client-server architecture
* D-Bus: A modern IPC system used by desktop environments and systemd
* Signal safety: Writing robust signal handlers (critical in C, less relevant in bash)

Relevant manual pages:
* <code>man 7 pipe</code> - Pipe overview
* <code>man 7 fifo</code> - Named pipe overview
* <code>man 7 signal</code> - Signal overview
* <code>man 7 unix</code> - Unix domain sockets
* <code>man bash</code> - Section on trap and job control

OS Lab 6 - Inter Process Communication

2025-11-14T15:05:52Z

Vserbu: /* Additional Resources */

== Objectives ==

Upon completion of this lab, you will be able to:

* Explain how the kernel provides IPC mechanisms and how bash exposes them to scripts.
* Use environment variables and <code>export</code> to pass configuration from parent processes to children.
* Construct pipelines with anonymous pipes to connect process standard streams.
* Create and use named pipes (FIFOs) for communication between unrelated processes.
* Send signals to processes and handle them with <code>trap</code> for asynchronous event-driven scripting.
* Demonstrate basic socket communication using existing utilities for network IPC.


== Introduction ==

In Lab 5, we explored bash scripting as a way to automate tasks by writing programs that the shell interprets. We learned how processes execute scripts, how to control flow with conditionals and loops, and how to structure code with functions. However, all of our scripts operated in isolation. Each script was a single process (or spawned child processes) that performed its task independently.

Real-world systems require processes to cooperate. A web server must communicate with a database. A shell pipeline connects the output of one program to the input of another. A service must respond to signals sent by the init system. This lab explores the kernel-provided mechanisms that enable processes to exchange data and coordinate their actions. We focus on five fundamental IPC mechanisms, all accessible from bash: environment variables, pipes, named pipes, signals, and sockets.

Understanding IPC is essential for system administration and software development. These mechanisms form the foundation of everything from command pipelines to distributed systems.


== Prerequisites ==


=== System Requirements ===

A running instance of the course-provided Linux virtual machine with SSH or direct terminal access.


=== Required Packages ===

The following packages must be installed:

<syntaxhighlight lang="bash">sudo apt update
sudo apt install -y caddy socat</syntaxhighlight>
* <code>caddy</code>: A modern HTTP server with automatic HTTPS. We use it to demonstrate socket communication.
* <code>socat</code>: A versatile networking tool that can work with Unix domain sockets.


=== Knowledge Prerequisites ===

You should be familiar with: - Process concepts from Lab 3 (PIDs, process hierarchy, file descriptors) - File permissions from Lab 4 (execute bit, ownership) - Bash scripting fundamentals from Lab 5 (shebangs, builtins, variables, quoting, exit status, redirection, loops, functions)


== Inter-Process Communication ==


=== What is IPC? ===

By default, processes are isolated from one another. Each process has its own memory space, file descriptor table, and execution context. This isolation provides security and stability, but it creates a problem: how can processes cooperate to accomplish complex tasks?

Inter-Process Communication (IPC) refers to the kernel-provided mechanisms that allow processes to exchange data and synchronize their actions. The kernel acts as an intermediary, providing channels, buffers, and signaling primitives that processes can use to communicate safely without violating isolation boundaries.

In this lab, we examine five IPC mechanisms arranged roughly by complexity:

# '''Environment Variables''': The simplest form of IPC. A parent process passes key-value configuration to its children via inherited environment variables. Communication is unidirectional (parent → child) and occurs only at process creation.
# '''Pipes''': The kernel creates a buffer connecting one process’s standard output to another’s standard input. Data flows in one direction through the pipe. Anonymous pipes exist only while the processes using them are running.
# '''Named Pipes (FIFOs)''': Like anonymous pipes, but visible in the filesystem. This persistence allows unrelated processes to connect to the same pipe by opening a file path.
# '''Signals''': Asynchronous notifications sent from one process to another (or from the kernel to a process). Signals interrupt the receiving process, which can catch and handle them or allow default behavior (often termination).
# '''Sockets''': Bidirectional communication channels that work across network boundaries or locally via Unix domain sockets. Multiple processes can connect to the same socket, enabling one-to-many communication patterns.

Each mechanism solves different problems and has different trade-offs in terms of complexity, performance, and flexibility.


=== Environment Variables and <code>export</code> ===


==== The Kernel’s Role ====

When a process forks, the child inherits a copy of the parent’s environment: a set of key-value string pairs maintained by the kernel for each process. The child can read these values and modify its own copy, but changes do not propagate back to the parent or to other processes. This inheritance mechanism provides a simple, unidirectional channel for passing configuration from parent to child.

Environment variables are not limited to shell scripts. Every process has an environment. When you run any program, it receives the environment from the shell that launched it. Programs written in C access this via the <code>environ</code> global variable or the third parameter to <code>main()</code>. Python uses <code>os.environ</code>. The environment is a universal convention for passing configuration.


==== Bash’s Role: <code>export</code> and <code>env</code> ====

In bash, variables are local to the shell process by default. When you set <code>name=value</code>, that variable exists in the shell’s memory but is '''not''' passed to child processes. The <code>export</code> builtin marks a variable for inclusion in the environment of future child processes:

<syntaxhighlight lang="bash">myvar="hello"
export myvar</syntaxhighlight>
Or, more concisely:

<syntaxhighlight lang="bash">export myvar="hello"</syntaxhighlight>
Once exported, all child processes started by this shell (scripts, programs, or subshells) will inherit <code>myvar</code> in their environment. To see the current environment, use the <code>env</code> command (or <code>printenv</code>), which prints all exported variables.

You can also set environment variables for a single command without affecting the shell:

<syntaxhighlight lang="bash">DEBUG=1 ./myscript.sh</syntaxhighlight>
This syntax sets <code>DEBUG=1</code> in the environment of <code>myscript.sh</code> only, without exporting it in the parent shell.

Common environment variables you’ve already been using include <code>PATH</code> (where bash searches for commands), <code>HOME</code> (your home directory), <code>USER</code> (your username), and <code>SHELL</code> (your login shell). These are all set by the login process and inherited by every subsequent process in your session.


==== When to Use Environment Variables ====

Environment variables are appropriate for: - Configuration that should be inherited by all child processes (e.g., locale settings, proxy configuration) - Passing secrets or credentials to programs without embedding them in command-line arguments (which are visible via <code>ps</code>) - Controlling program behavior via well-known variables like <code>PATH</code>, <code>LD_LIBRARY_PATH</code>, or <code>TZ</code>

They are '''not''' suitable for: - Runtime communication between already-running processes (use pipes, sockets, or signals) - Large amounts of data (environment is limited in size, typically a few megabytes) - Bi-directional communication (child changes don’t affect parent)


=== Pipes ===


==== The Kernel’s Pipe Mechanism ====

A pipe is a one-way data channel maintained in kernel memory. When you create a pipe, the kernel allocates a buffer (typically 64 KB on Linux) and returns two file descriptors: one for writing and one for reading. Data written to the write end is buffered by the kernel and can be read from the read end in FIFO (first-in, first-out) order.

Pipes are anonymous: they have no name in the filesystem. They exist only as long as at least one process holds a file descriptor to them. When all processes close their references to a pipe, the kernel deallocates it.

The key insight from Lab 3: a pipeline like <code>cat file.txt | grep "error" | wc -l</code> creates multiple processes (all in the same process group) connected by pipes. The kernel sets up the file descriptors so that <code>cat</code>’s stdout is connected to <code>grep</code>’s stdin, and <code>grep</code>’s stdout is connected to <code>wc</code>’s stdin. The processes run concurrently, with data flowing through kernel buffers as it’s produced and consumed.


==== Bash’s Pipe Operator ====

Bash creates pipes using the <code>|</code> operator. The syntax is simple:

<syntaxhighlight lang="bash">command1 | command2</syntaxhighlight>
This creates a pipe and starts two processes. Bash configures <code>command1</code>’s stdout (FD 1) to point to the pipe’s write end and <code>command2</code>’s stdin (FD 0) to point to the pipe’s read end. The commands execute concurrently.

Longer pipelines work the same way:

<syntaxhighlight lang="bash">cat data.txt | sort | uniq | wc -l</syntaxhighlight>
This creates three pipes connecting four processes. Data flows left-to-right through kernel buffers.


==== Pipes in Scripts ====

You can use pipes inside scripts just as you would interactively:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

# Count unique IP addresses in an access log
cat /var/log/access.log | cut -d' ' -f1 | sort | uniq | wc -l</syntaxhighlight>
Pipes are particularly powerful when combined with bash’s process substitution feature <code><(command)</code>, but that’s beyond the scope of this introductory lab.


==== When to Use Pipes ====

Pipes are ideal for: - Connecting the output of one program to the input of another in a linear processing chain - Streaming data processing where data is generated and consumed incrementally - Quick, one-off data transformations at the command line

They are '''not''' suitable for: - Bi-directional communication (data flows one way only) - Communication between unrelated processes that weren’t started in a pipeline - Persistent communication (pipe disappears when processes exit)


=== Named Pipes (FIFOs) ===


==== The Kernel’s FIFO Mechanism ====

A named pipe, or FIFO (First-In, First-Out), is a pipe with a name in the filesystem. Unlike anonymous pipes, FIFOs persist as filesystem entries (though the data buffer is still in kernel memory). Any process with appropriate permissions can open the FIFO by its path, allowing unrelated processes to communicate.

When a process opens a FIFO for reading, it blocks until another process opens the same FIFO for writing (and vice versa). Once both ends are open, data flows through the kernel buffer just like an anonymous pipe. When all processes close their connections, the FIFO remains as a filesystem entry but the kernel buffer is deallocated.

You can identify a FIFO in <code>ls -l</code> output by the leading <code>p</code> in the permission string:

<pre>prw-r--r-- 1 user user 0 Nov 6 10:00 myfifo</pre>

==== Creating FIFOs with <code>mkfifo</code> ====

The <code>mkfifo</code> command creates a named pipe:

<syntaxhighlight lang="bash">mkfifo /tmp/myfifo</syntaxhighlight>
Now two unrelated processes can communicate by opening this file. One writes to it:

<syntaxhighlight lang="bash">echo "Hello from writer" > /tmp/myfifo</syntaxhighlight>
This command will block until a reader appears. In another terminal (or in the background), a reader can consume the data:

<syntaxhighlight lang="bash">cat < /tmp/myfifo</syntaxhighlight>
When the reader connects, the writer unblocks, the message flows through the kernel buffer, and both commands complete.


==== When to Use Named Pipes ====

Named pipes are useful for: - Communication between unrelated processes that start at different times - Producer-consumer patterns where one process generates data and another processes it - Simple IPC without needing network sockets or shared files

They are '''not''' suitable for: - Multiple simultaneous readers or writers (FIFO semantics become unpredictable) - Persistent data storage (data is lost when all processes disconnect) - Bi-directional communication (like anonymous pipes, FIFOs are one-way)


=== Signals and <code>trap</code> ===


==== The Kernel’s Signal Mechanism ====

A signal is an asynchronous notification sent to a process. Signals can be sent by other processes (via the <code>kill</code> system call) or by the kernel itself in response to events like segmentation faults, keyboard interrupts (Ctrl+C), or child process termination.

When the kernel delivers a signal to a process, it interrupts the process’s normal execution. The process can respond in one of three ways:

# '''Default Action''': Each signal has a default behavior, often terminating the process. For example, <code>SIGTERM</code> (signal 15) gracefully terminates, while <code>SIGKILL</code> (signal 9) forces immediate termination.
# '''Ignore''': The process can choose to ignore certain signals (except <code>SIGKILL</code> and <code>SIGSTOP</code>, which cannot be caught or ignored).
# '''Custom Handler''': The process can register a function (signal handler) to execute when the signal arrives. This allows the process to perform cleanup or take other actions before deciding whether to continue, terminate, or take other action.

Common signals: - <code>SIGINT</code> (2): Sent by Ctrl+C. Default: terminate. - <code>SIGTERM</code> (15): Polite request to terminate. Default: terminate. Most services handle this to perform clean shutdown. - <code>SIGKILL</code> (9): Immediate termination. Cannot be caught or ignored. Used as a last resort. - <code>SIGHUP</code> (1): Historically “hang up” (modem disconnected). Often used to tell daemons to reload configuration. - <code>SIGCHLD</code> (17): Sent to a parent when a child process terminates. - <code>SIGUSR1</code> (10) and <code>SIGUSR2</code> (12): User-defined signals for custom purposes.

Signals are sent by PID:

<syntaxhighlight lang="bash">kill -TERM 1234 # Send SIGTERM to process 1234
kill -9 1234 # Send SIGKILL to process 1234
kill -HUP 1234 # Send SIGHUP to process 1234</syntaxhighlight>
You can also use the <code>%n</code> job notation from Lab 3 to send signals to background jobs.


==== Bash’s <code>trap</code> Builtin ====

The <code>trap</code> builtin allows a bash script to register a handler for incoming signals:

<syntaxhighlight lang="bash">trap 'echo "Caught SIGINT"; exit' INT</syntaxhighlight>
This tells bash: “When SIGINT arrives, execute the command <code>echo "Caught SIGINT"; exit</code>.” The handler can be any bash command or function.

Common pattern for cleanup on exit:

<syntaxhighlight lang="bash">#!/bin/bash
set -euo pipefail

cleanup() {
echo "Cleaning up temporary files..."
rm -f /tmp/myscript.*
}

trap cleanup EXIT

# Script body
echo "Running..."
sleep 10
echo "Done"

# cleanup() is automatically called on normal exit, Ctrl+C, or errors (with set -e)</syntaxhighlight>
The special signal <code>EXIT</code> isn’t a real signal; it’s a bash pseudo-signal that fires whenever the script exits for any reason.


==== When to Use Signals ====

Signals are appropriate for: - Event-driven scripts that respond to external events - Graceful shutdown and cleanup on termination - Daemon control (reload config with <code>SIGHUP</code>, graceful restart with <code>SIGTERM</code>) - Inter-process coordination where one process needs to notify another of state changes

They are '''not''' suitable for: - Transferring data (signals carry almost no information, just the signal number) - Reliable communication (signals can be lost or delayed) - Complex coordination (race conditions are common)


=== Sockets ===


==== The Kernel’s Socket Mechanism ====

A socket is a bidirectional communication endpoint. Unlike pipes, sockets support two-way data flow. Unlike named pipes, sockets support multiple concurrent connections, making them suitable for client-server architectures.

There are two main types:

# '''Network Sockets''': Use TCP or UDP to communicate over IP networks. These work across machines and are the foundation of the internet.
# '''Unix Domain Sockets''': Use file paths (like named pipes) but support bidirectional communication and connection multiplexing. These work only on the same machine but are faster than network sockets.

When a server process binds to a socket, it listens for incoming connections. Multiple client processes can connect to the same server socket. Each connection is independent, with its own bidirectional channel. This one-to-many pattern distinguishes sockets from pipes and FIFOs.

For network sockets, the server binds to a port number (e.g., port 80 for HTTP). For Unix domain sockets, it binds to a filesystem path (e.g., <code>/tmp/myservice.sock</code>).


==== Socket Communication from Bash ====

While bash doesn’t have native socket support, we can use existing tools to demonstrate socket communication without writing low-level code:

* '''caddy''': A modern web server that can listen on both network and Unix domain sockets
* '''curl''': A command-line HTTP client that supports Unix domain sockets
* '''socat''': A general-purpose networking tool for creating and connecting to various socket types

These tools abstract the complexity of socket programming, allowing us to focus on the conceptual model.


==== When to Use Sockets ====

Sockets are ideal for: - Client-server applications with multiple concurrent clients - Networked communication across machines - Bidirectional data exchange - Services that need to accept connections from many processes

They are '''not''' necessary for: - Simple one-to-one, one-way communication (use pipes instead) - Configuration passing (use environment variables) - Asynchronous notifications (use signals)


== Hands-on Exercises ==


=== Exercise A: Environment Variables and <code>export</code> ===

This exercise demonstrates how environment variables are inherited by child processes but not propagated back to parents.

'''Steps:'''

# Check your current environment. Run <code>env | head -n 10</code> and observe some of the variables already set.
# Create a shell variable without exporting it: <code>myvar="not exported"</code>.
# Start a subshell with <code>bash</code> and try to read <code>myvar</code> with <code>echo "$myvar"</code>. It should be empty. Exit the subshell.
# Back in your original shell, export the variable: <code>export myvar="exported now"</code>.
# Start a subshell again with <code>bash -c 'echo "In child: $myvar"'</code> and verify that <code>myvar</code> is now accessible.
# In a subshell, modify the variable: <code>bash -c 'myvar="changed in child"; echo "Child modified: $myvar"'</code>.
# Print <code>myvar</code> in the parent shell: <code>echo "Parent still has: $myvar"</code>. Observe that the parent’s value is unchanged.
# Demonstrate setting an environment variable for a single command: <code>GREETING="Hello" bash -c 'echo $GREETING'</code>.
# Verify that <code>GREETING</code> is not set in your current shell: <code>echo "GREETING in parent: $GREETING"</code> (should be empty).
# Use <code>env</code> to run a command with a specific environment: <code>env DEBUG=1 bash -c 'echo "DEBUG=$DEBUG"'</code>.

'''Deliverable A:''' Provide the output showing: the subshell cannot see the unexported variable, the subshell can see the exported variable, the parent is unaffected by child changes, and single-command environment variable setting.


=== Exercise B: Pipes in Practice ===

This exercise explores anonymous pipes and how they connect processes.

'''Steps:'''

# Use a simple pipe to count lines: <code>cat /etc/passwd | wc -l</code>. Observe the result.
# Build a longer pipeline to find how many unique shells are in use: <code>cat /etc/passwd | cut -d: -f7 | sort | uniq</code>. Count them manually or pipe to <code>wc -l</code>.
# Demonstrate that processes in a pipeline run concurrently. Run <code>yes | head -n 5</code>. The <code>yes</code> command produces infinite output, but <code>head</code> reads only 5 lines and then exits, causing <code>yes</code> to receive a <code>SIGPIPE</code> and terminate.
# Create a sample log file for analysis:

<syntaxhighlight lang="bash">cat > /tmp/lab6_sample.log <<'EOF'
2024-01-15 10:00:00 INFO Application started
2024-01-15 10:05:23 ERROR Database connection failed
2024-01-15 10:12:45 WARN Connection timeout
2024-01-15 10:15:00 INFO Retry successful
2024-01-15 10:20:00 ERROR Invalid configuration
2024-01-15 10:25:00 WARN Low memory
EOF</syntaxhighlight>
<ol start="5" style="list-style-type: decimal;">
<li>Use a pipeline to count ERROR entries: <code>grep "ERROR" /tmp/lab6_sample.log | wc -l</code>.</li>
<li>Use a pipeline to extract and count unique log levels: <code>cut -d' ' -f3 /tmp/lab6_sample.log | sort | uniq -c</code>.</li>
<li>Combine multiple operations: Find the timestamps of all ERROR entries: <code>grep "ERROR" /tmp/lab6_sample.log | cut -d' ' -f1,2</code>.</li></ol>

'''Deliverable B:''' Provide the output from the <code>/etc/passwd</code> shell analysis, the <code>yes | head -n 5</code> demonstration, and the log file analysis commands showing ERROR count and unique log levels with counts.


=== Exercise C: Named Pipes (FIFOs) ===

This exercise demonstrates persistent named pipes and communication between unrelated processes.

'''Steps:'''

# Create a named pipe: <code>mkfifo /tmp/lab6_fifo</code>.
# Verify it exists and note its type: <code>ls -l /tmp/lab6_fifo</code>. The leading <code>p</code> indicates a FIFO.
# In one terminal, start a reader that will block: <code>cat < /tmp/lab6_fifo</code>. Leave this running.
# In a second terminal, write to the FIFO: <code>echo "Hello via FIFO" > /tmp/lab6_fifo</code>.
# Observe that the reader in the first terminal unblocks, displays the message, and exits.
# Demonstrate that the FIFO persists. List it again: <code>ls -l /tmp/lab6_fifo</code>.
# Test a more complex scenario. In terminal 1: <code>while read line; do echo "Received: $line"; done < /tmp/lab6_fifo</code>.
# In terminal 2, send multiple messages:

<syntaxhighlight lang="bash">echo "Message 1" > /tmp/lab6_fifo
echo "Message 2" > /tmp/lab6_fifo
echo "Message 3" > /tmp/lab6_fifo</syntaxhighlight>
<ol start="9" style="list-style-type: decimal;">
<li>Observe the messages being received. Press Ctrl+C in terminal 1 to stop the reader.</li>
<li>Remove the FIFO: <code>rm /tmp/lab6_fifo</code>.</li></ol>

'''Deliverable C:''' Provide the <code>ls -l</code> output showing the FIFO type, screenshots or output from both terminals showing the message exchange, and a brief explanation of how the FIFO persists between writes.


=== Exercise D: Signals and <code>trap</code> ===

This exercise demonstrates signal handling in bash using interactive commands.

'''Steps:'''

# Start a simple sleep command: <code>sleep 30</code>. Press Ctrl+C to interrupt it. Observe that it terminates immediately.
# Now run a command that ignores SIGINT: <code>trap 'echo "Caught SIGINT, ignoring..."' INT; sleep 30</code>. Press Ctrl+C. The trap catches the signal and the sleep continues.
# Demonstrate cleanup on exit. Run this compound command:

<syntaxhighlight lang="bash">trap 'echo "Cleanup: removing temp file"; rm -f /tmp/lab6_test.txt' EXIT; \
touch /tmp/lab6_test.txt; \
echo "File created. Press Ctrl+C or wait..."; \
sleep 10; \
echo "Normal exit"</syntaxhighlight>
<ol start="4" style="list-style-type: decimal;">
<li>Try both: let it complete normally, then run it again and interrupt with Ctrl+C. Observe cleanup happens both times.</li>
<li>Start a background sleep: <code>sleep 100 &</code>. Note the PID displayed.</li>
<li>Send SIGTERM to it: <code>kill -TERM <pid></code> (replace <code><pid></code> with the actual PID). Verify it terminated: <code>jobs</code>.</li>
<li>Start another background process that will ignore SIGTERM:</li></ol>

<syntaxhighlight lang="bash">(trap 'echo "Caught SIGTERM, staying alive"' TERM; \
while true; do echo "Running..."; sleep 5; done) &</syntaxhighlight>
<ol start="8" style="list-style-type: decimal;">
<li>Note the PID, then send SIGTERM: <code>kill -TERM <pid></code>. Observe the trap message.</li>
<li>Send SIGKILL to force termination: <code>kill -9 <pid></code>. This cannot be caught.</li>
<li>Verify all background jobs are gone: <code>jobs</code>.</li></ol>

'''Deliverable D:''' Provide output showing: the trapped SIGINT message, cleanup on both normal exit and Ctrl+C, the SIGTERM being caught with the trap message, and SIGKILL forcing termination.


=== Exercise E: Socket Communication Basics ===

This exercise provides a brief introduction to socket communication using existing tools.

'''Steps:'''

# Create a simple static site directory: <code>mkdir -p /tmp/lab6_site && echo "<h1>Hello from Caddy</h1>" > /tmp/lab6_site/index.html</code>.
# Start Caddy as a file server listening on a Unix domain socket: <code>caddy file-server --root /tmp/lab6_site --listen unix//tmp/caddy.sock &</code>. Note the PID.
# Wait a moment for Caddy to start. Verify the socket exists: <code>ls -l /tmp/caddy.sock</code>. Note the <code>s</code> type indicating a socket.
# Use <code>curl</code> to make an HTTP request via the Unix domain socket: <code>curl -v --unix-socket /tmp/caddy.sock http://localhost/</code>.
# Observe the response. Note that the communication is bidirectional: you sent an HTTP request, and the server responded with the HTML content.
# (Optional) Open multiple terminals and run <code>curl</code> simultaneously several times. Each request is handled independently, demonstrating the one-to-many capability of sockets.
# Stop Caddy by sending <code>SIGTERM</code>: <code>kill -TERM <caddy_pid></code> or use <code>pkill caddy</code>.
# Clean up: <code>rm -rf /tmp/lab6_site /tmp/caddy.sock</code>.

'''Deliverable E:''' Provide the <code>ls -l</code> output showing the socket file, the <code>curl</code> output demonstrating the request and response (especially the HTTP headers and HTML body), and a brief explanation (2-3 sentences) of how this differs from a named pipe in terms of directionality and connection multiplexing.


== Scripting Challenges ==


=== Challenge 1: Log Aggregator with Named Pipes ===

Write a script <code>/tmp/lab6_log_aggregator.sh</code> that aggregates log messages from multiple sources using named pipes.

'''Requirements:'''

* Create three named pipes: <code>/tmp/log_fifo1</code>, <code>/tmp/log_fifo2</code>, <code>/tmp/log_fifo3</code>.
* Start three background processes that each write timestamped messages to one of the FIFOs (simulating different log sources). Each should write 5 messages at 1-second intervals.
* Implement a main loop that reads from all three FIFOs simultaneously (hint: use <code>select</code> via <code>read</code> with timeout, or use multiple background readers).
* Write all received messages to a combined log file <code>/tmp/aggregated.log</code> with timestamps.
* Trap <code>SIGTERM</code> to clean up: kill background processes, remove FIFOs, and exit gracefully.
* Use: <code>set -euo pipefail</code>, functions, <code>trap</code>, <code>mkfifo</code>, background processes (<code>&</code>), proper cleanup.

'''Test:'''

<syntaxhighlight lang="bash">chmod +x /tmp/lab6_log_aggregator.sh
/tmp/lab6_log_aggregator.sh &
AGG_PID=$!
sleep 10
kill -TERM $AGG_PID
wait
cat /tmp/aggregated.log</syntaxhighlight>
'''Deliverable Challenge 1:''' - Complete script with comments - Contents of <code>/tmp/aggregated.log</code> showing interleaved messages from all three sources - Brief explanation (2-3 sentences) of why named pipes were necessary here instead of anonymous pipes


=== Challenge 2: Graceful Service Controller ===

Write a script <code>/tmp/lab6_service_controller.sh</code> that manages a long-running service and responds to signals.

'''Requirements:'''

* The script acts as a daemon that runs indefinitely, printing a heartbeat message every 5 seconds.
* Accept one optional argument: a “config file” path. If provided, read a setting (e.g., <code>INTERVAL=10</code>) from the file to control the heartbeat interval.
* Trap <code>SIGHUP</code>: Reload the configuration file and adjust the interval dynamically without restarting the script. Print “Configuration reloaded.”
* Trap <code>SIGTERM</code>: Perform graceful shutdown. Print “Shutting down gracefully…”, wait 2 seconds, then exit cleanly.
* Trap <code>SIGUSR1</code>: Export the current status to <code>/tmp/service_status.txt</code> (e.g., uptime, number of heartbeats sent, current interval). Print “Status exported.”
* Trap <code>EXIT</code>: Perform cleanup. Print “Service stopped.”
* Maintain internal state: count the number of heartbeats sent, track start time.
* Use: <code>set -euo pipefail</code>, functions, <code>trap</code> for multiple signals, variables for state, a loop, cleanup handler.

'''Test:'''

<syntaxhighlight lang="bash">echo "INTERVAL=3" > /tmp/service.conf
chmod +x /tmp/lab6_service_controller.sh
/tmp/lab6_service_controller.sh /tmp/service.conf &
SVC_PID=$!
sleep 10
kill -USR1 $SVC_PID # Export status
cat /tmp/service_status.txt
echo "INTERVAL=1" > /tmp/service.conf
kill -HUP $SVC_PID # Reload config
sleep 5
kill -TERM $SVC_PID # Graceful shutdown
wait</syntaxhighlight>
'''Deliverable Challenge 2:''' - Complete script with comments - Output showing heartbeats before and after <code>SIGHUP</code> (with visible interval change) - Contents of <code>/tmp/service_status.txt</code> after <code>SIGUSR1</code> - Output showing graceful shutdown message after <code>SIGTERM</code>


== Reference: Common IPC Patterns ==

Quick reference for IPC mechanisms covered in this lab:

'''Environment Variables:'''

<syntaxhighlight lang="bash"># Export a variable for child processes
export VAR="value"

# Set for one command only
VAR="value" command

# View all environment variables
env
printenv</syntaxhighlight>
'''Anonymous Pipes:'''

<syntaxhighlight lang="bash"># Simple pipeline
command1 | command2

# Multi-stage pipeline
cat file.txt | grep "pattern" | sort | uniq</syntaxhighlight>
'''Named Pipes:'''

<syntaxhighlight lang="bash"># Create a FIFO
mkfifo /path/to/fifo

# Write to FIFO (blocks until reader connects)
echo "data" > /path/to/fifo

# Read from FIFO (blocks until writer connects)
cat < /path/to/fifo

# Remove FIFO
rm /path/to/fifo</syntaxhighlight>
'''Signals:'''

<syntaxhighlight lang="bash"># Send signal by name
kill -TERM <pid>
kill -HUP <pid>

# Send signal by number
kill -15 <pid>

# Force kill (cannot be caught)
kill -9 <pid>

# Trap signals in a script
trap 'echo "Caught signal"' INT TERM
trap cleanup EXIT

# Define cleanup function
cleanup() {
echo "Cleaning up..."
rm -f /tmp/myfiles.*
}</syntaxhighlight>
'''Sockets (using existing tools):'''

<syntaxhighlight lang="bash"># Start a server on Unix domain socket (using socat)
socat UNIX-LISTEN:/tmp/service.sock,fork EXEC:'/usr/bin/myhandler'

# Connect as client (using socat)
echo "request" | socat - UNIX-CONNECT:/tmp/service.sock

# HTTP via Unix socket (using curl)
curl --unix-socket /tmp/service.sock http://localhost/path</syntaxhighlight>

== Common Patterns Table ==

{| class="wikitable"
|-
! Mechanism
! Direction
! Persistence
! Use Case
|-
| Environment Variables
| Parent → Child (one-way)
| Inherited at fork
| Configuration, credentials
|-
| Pipes (<code>\|</code>)
| One-way
| Ephemeral (process lifetime)
| Command chaining, streaming
|-
| Named Pipes (FIFO)
| One-way
| Filesystem entry persists
| Unrelated process communication
|-
| Signals
| One-way (notification)
| Asynchronous event
| Process control, event notification
|-
| Sockets
| Bidirectional
| Filesystem entry persists (Unix domain)
| Client-server, network services
|}


== Deliverables and Assessment ==

Submit a single document (PDF or similar) containing:

'''Exercise Deliverables:''' - Exercise A: Outputs demonstrating export behavior, parent-child isolation, and single-command environment variables - Exercise B: Pipeline outputs and complete analysis script - Exercise C: FIFO creation output, producer/consumer scripts with sample output - Exercise D: Complete daemon simulation script with signal handling demonstrations - Exercise E: Socket file listing, curl output with HTTP headers, explanation of socket vs FIFO differences

'''Challenge Deliverables:''' - Challenge 1: Complete log aggregator script, aggregated log contents, explanation - Challenge 2: Complete service controller script, outputs demonstrating all signal handlers (SIGHUP reload, SIGUSR1 status export, SIGTERM shutdown)

'''Additional:''' - Each deliverable should include command outputs (screenshots or text) and brief explanations where requested. - For scripts, include the complete, commented source code and example execution output.


== Additional Resources ==

This lab covers the fundamental IPC mechanisms accessible from bash. You’ve learned how processes inherit environment variables, communicate via pipes, respond to signals, and use sockets for network communication. These concepts form the foundation for system administration, scripting, and understanding how complex systems coordinate.

For further study:
* Advanced IPC: Shared memory, message queues, semaphores (typically used in C/C++ programs, not bash)
* Network programming: TCP/UDP sockets, client-server architecture
* D-Bus: A modern IPC system used by desktop environments and systemd
* Signal safety: Writing robust signal handlers (critical in C, less relevant in bash)

Relevant manual pages:
* <code>man 7 pipe</code> - Pipe overview
* <code>man 7 fifo</code> - Named pipe overview
* <code>man 7 signal</code> - Signal overview
* <code>man 7 unix</code> - Unix domain sockets
* <code>man bash</code> - Section on trap and job control