Session 2: Internet security

Class page | Class recording

Assignments

For each of the following systems, research and document 3 parts what threat does it address? what’s the trust model? what’s the residual risk?

• PGP (end to end email security)
• SSH (secure remote access)
• VPN / IPsec (network-layer tunneling)
• MACsec (link-layer encryption)
• DNS Security (DNSSEC & DNS spoofing)
• IDS / IPS (detection vs. prevention)

Complete these exercises:

• TLS Handshake Trace
• Port Scan & Firewall

Class

The session started with a review of the first week's assignments. Students shared their documentation and demonstrated practical work. Radia Perlman and Charlie Kaufman answered questions about public key cryptography and RSA, explaining why the algorithm relies on the difficulty of factoring large numbers. They also shared some of the history behind RSA and public key cryptography.

The main lecture was given by Ralph Droms, who introduced the history of the Internet and explained how many of today's networking technologies evolved over time. He covered how encryption is applied in practice through TLS and HTTPS before introducing network segmentation, firewalls, VLANs, and other techniques used to protect computer networks.

After that, there were some talks about the assignments for this session and a few tools to experiment with.

Tools

After the class, I was a bit overwhelmed by all the terms and information. Some I had heard of, some I have experience with, and others were completely new to me. The same was true for the tools.

I spent a good amount of time trying out TCPdump at my local coffee house, looking at the background internet noise that Neil had mentioned. Before starting to experiment, I made a table of the tools and what they do. Some are used to observe, others to scan, and some are used for configuration. I also sorted them into terminal, terminal UI, and graphical UI tools.

Here is the table I came up with:

Nmap

Looking into Nmap, I found this tutorial from GetCyber. Since this was the class VPN environment, I thought it would be fun to scan the network and see if I could find my friend Andri there.

First I made a list of the IP-addresses that were up:

nmap -sn 192.168.80.* | grep "Nmap scan report for" | cut -d " " -f 5 > hostup.txt

That just made a list with the IP-address that were up that I could use for the next command:

sudo nmap -sS -A -Pn -iL hostup.txt -oN full_scan.txt

This command scans all the IP-addresses listed in hostup.txt and saves the results to full_scan.txt. Since I had already identified the active hosts, I used -Pn to tell nmap to skip the host discovery step and assume the listed hosts were on-line.

When analyzing full_scan.txt, I looked for anything containing ff-cs-. Since my own machine was named ff-cs-hanndoddi, I knew what to look for. I could see some of the faculty in the scan, but the students looked well hidden and there was no sign of Andri.

Then, to my surprise, I spotted my fellow student ff-cs-yosuke-tsuchiya. It looked like the information came from an SMTP service running on port 25, so I decided to scan that port in a bit more detail:

nmap -p 25 --script smtp-commands -iL hostup.txt | grep -E "smtp-commands|Nmap scan report" > ~/smtp_results.txt

Doing that I was not able to find other students but since I now knew where Yosuke was I thought it would at least be nice if I could at least leave him a note. I wondered if could slip him a .txt file on his desktop just like a mailbox in real life but looking into that seemed impossible. Reading more about what SMTP actually was, I learned it stands for Simple Mail Transfer Protocol so perhaps I could send him a message after all. I learned that telnet could work so I tried this command:

telnet <yosuke-ip-address> 25

First it said trying and then it said connected!

I've never used this before so I had to look up how to actually send something and I used this.

EHLO ff-cs-hanndoddi
MAIL FROM: hanndoddi@ff-cs-hanndoddi
RCPT TO: ubuntu@ff-cs-yosuke-tsuchiya
DATA
Subject: hello

Hello Yosuke, doddi here :) saw an open port

.
quit

I'm not exactly sure where the message will end up. It looks like local mail is typically stored somewhere under /var/mail/, so if everything worked Yosuke should eventually be able to read it.

Check out Yosuke's documentation page to see if it got delivered. I should probably also see if I can open my mailbox.

Assignment work

OSI model

I first looked at the Open Systems Interconnection (OSI) model developed by the International Organization for Standardization (ISO). It divides network communication into seven layers, from the physical transmission of bits up to the applications we interact with. To get a better overview of the assignment, I made a OSI diagram and a table showing where each of the six security technologies fits within the model.

graph TD
    %% Theme style for black text
    classDef blackText fill:#fff,stroke:#000,stroke-width:1px,color:#000;

    %% Color styles with forced black text color
    classDef layer7 fill:#e1f5fe,stroke:#0288d1,stroke-width:2px,color:#000;
    classDef layer6 fill:#e8f5e9,stroke:#388e3c,stroke-width:2px,color:#000;
    classDef layer5 fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#000;
    classDef layer4 fill:#fce4ec,stroke:#c2185b,stroke-width:2px,color:#000;
    classDef layer3 fill:#efebe9,stroke:#795548,stroke-width:2px,color:#000;
    classDef layer2 fill:#ede7f6,stroke:#5e35b1,stroke-width:2px,color:#000;
    classDef layer1 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#000;

    L7["Layer 7: Application<br/>(Interface, HTTP, FTP, DNS)"]:::layer7
    L6["Layer 6: Presentation<br/>(Formatting, Encryption, SSL)"]:::layer6
    L5["Layer 5: Session<br/>(Connection Management, RPC)"]:::layer5
    L4["Layer 4: Transport<br/>(Reliability, TCP, UDP)"]:::layer4
    L3["Layer 3: Network<br/>(Routing, IP, Packets)"]:::layer3
    L2["Layer 2: Data Link<br/>(MAC Addresses, Frames)"]:::layer2
    L1["Layer 1: Physical<br/>(Cables, Hubs, Raw Bits)"]:::layer1

    L7 --> L6
    L6 --> L5
    L5 --> L4
    L4 --> L3
    L3 --> L2
    L2 --> L1

    L1 -.-> L2 -.-> L3 -.-> L4 -.-> L5 -.-> L6 -.-> L7

SSH - Secure Shell

I've used SSH to connect to things for quite a while, mainly GitHub, GitLab, and a few servers. I've never really understood much of what happens behind the scenes, so I decided to dig a little deeper. I've mostly used SSH with key authentication, although it can also be used with passwords. The first time I connected to the class VM I used a password, but later I switched to an SSH key. Besides being more convenient since I no longer have to remember the password, it's also more secure, especially if password authentication is disabled.

I learned that before SSH became common, Telnet was often used for remote access. Since Telnet sends usernames, passwords, and commands in plain text, anyone able to capture the traffic could read them. SSH solves this by encrypting the entire session, protecting it from eavesdropping and tampering.

Trust model

SSH relies on public key cryptography and trust in the server's identity.

When connecting for the first time, the client receives the server's public host key and displays its fingerprint. If the user accepts and stores this fingerprint, future connections can verify that the client is talking to the same server. This helps protect against man-in-the-middle attacks.

Like mentioned authentication can then happen using either a password or, more commonly, an SSH key pair where the private key stays on the client's computer and the public key is stored on the server.

Residual Risk

SSH is generally very secure, but some risks still remain:

• Accepting the wrong host fingerprint during the first connection.
• Weak or stolen passwords if password authentication is enabled.
• Theft of a user's private SSH key.
• A compromised client or server, where encryption cannot protect data after it reaches the endpoint.
• Poor server configuration or outdated SSH software.

SSH model diagram After gaining some better understanding of ssh and looking at models I made this mermaid model:

sequenceDiagram
    autonumber
    actor Client
    participant Server

    %% Connection Phase
    rect rgb(230, 242, 255)
        Note over Client, Server: Phase 1: Connection & Negotiation
        Client->>Server: Connect request (TCP Port 22)
        Server-->>Client: SSH Protocol Version & Host Public Key
    end

    %% Key Exchange Phase
    rect rgb(235, 250, 235)
        Note over Client, Server: Phase 2: Diffie-Hellman Key Exchange
        Client->>Server: Client Key Exchange / Cipher Negotiation
        Server->>Client: Server proves identity using Host Key
        Note over Client, Server: Shared Session Key Established
    end

    %% Authentication Phase
    rect rgb(255, 245, 215)
        Note over Client, Server: Phase 3: User Authentication
        Client->>Server: Auth Request (Public Key / Password)
        Server-->>Client: Challenge/Signature Verification
    end

    %% Secure Session Phase
    rect rgb(250, 230, 250)
        Note over Client, Server: Phase 4: Encrypted Secure Session
        Client->>Server: Request Shell/Command Execution
        Client->>Server: Encrypted Data Traffic <->
        Server-->>Client: Encrypted Command Output
    end

VPN / IPsec - Network-layer Tunneling

We use a VPN to connect to the class network, so I was already familiar with using one. Like SSH, though, I wanted to take a closer look at how it actually works.

The assignment mentions IPsec, but I discovered that IPsec is just one technology used to build a VPN. During this course we have been using WireGuard, which is another VPN technology that also operates at the network layer (Layer 3 of the OSI model). While researching, I also came across OpenVPN, which uses TLS over UDP or TCP, and SSL VPNs, which typically provide secure remote access through a web browser.

During the course we connect to the class VPN before accessing the virtual machines. To be able to conect we got a config file. This allowed us to communicate with the internal network through an encrypted tunnel instead of exposing our traffic directly on the Internet.

Local machine
   │
   │  Encrypted Tunnel (WireGuard/IPsec)
============================ Internet ============================
   │
VPN Server
   │
   │  Plain IP traffic inside the trusted network
Class VM

Trust Model

The VPN trust model is a little different from SSH. Before any traffic is sent, the client and VPN server authenticate each other using cryptographic keys. Once the tunnel has been established, all of my network traffic to the class network travels through that encrypted connection. In practice, this means I trust the VPN server to handle my traffic correctly and securely before forwarding it to its final destination.

Residual Risk

Even though a VPN provides an encrypted tunnel, some risks still remain:

• The VPN server can see and forward decrypted traffic unless it is protected again by end-to-end encryption such as HTTPS.
• If the VPN server or the client device is compromised, the encrypted tunnel no longer provides protection.
• Weak or stolen authentication keys can allow an attacker to connect to the VPN.
• Traffic analysis is still possible. While the contents are encrypted, an observer can often see packet sizes, timing, and that a VPN connection exists.
• Incorrect configuration can weaken the security of the VPN or accidentally expose traffic outside the encrypted tunnel.

---
config:
  look: handDrawn
  theme: neutral
---
graph TD

    %% Node Styling Definitions %%
    classDef client fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff;
    classDef public fill:#e74c3c,stroke:#c0392b,stroke-width:2px,color:#fff;
    classDef gateway fill:#2ecc71,stroke:#27ae60,stroke-width:2px,color:#fff;
    classDef private fill:#9b59b6,stroke:#8e44ad,stroke-width:2px,color:#fff;

    %% Subgraphs & Architecture %%
    subgraph Clients ["User Endpoints"]
        A1["💻 Local Machine"]:::client

    end

    subgraph Internet ["🌐 Public Network"]
        B["☁️ Unsecured Internet"]:::public
    end

    subgraph Security ["🔒 VPN Gateway"]
        C["🛡️ Firewall & Decryptor"]:::gateway
    end

    subgraph Intranet [" Private Network"]
        D["💾 Internal Servers"]:::private
        E["🗄️ Secure Database"]:::private
    end

    %% Network Connections & Flow %%
    A1 -.->|1. Initiates Link| B


    B ==>|2. Encrypted Tunnel <br> IPsec / SSL / WireGuard| C

    C -->|3. Forward Cleared Traffic| D
    C -->|3. Forward Cleared Traffic| E

    %% Component Overrides %%
    style Clients fill:none,stroke:#3498db,stroke-width:2px,stroke-dasharray: 5 5
    style Internet fill:none,stroke:#e74c3c,stroke-width:2px,stroke-dasharray: 5 5
    style Security fill:none,stroke:#2ecc71,stroke-width:2px,stroke-dasharray: 5 5
    style Intranet fill:none,stroke:#9b59b6,stroke-width:2px,stroke-dasharray: 5 5

DNS - Domain Name System

I've always understood DNS as the phone book of the Internet, translating a website's domain name into an IP address so computers know where to connect. Looking into it a bit deeper, I learned that DNS itself was originally designed without any way to verify that a response was genuine. This made it possible for attackers to perform DNS spoofing or cache poisoning attacks and redirect users to malicious websites.

DNSSEC (Domain Name System Security Extensions) addresses this by adding digital signatures to DNS records. Rather than encrypting the data, it allows DNS resolvers to verify that the information they receive is authentic and has not been modified in transit.

Trust model

DNSSEC relies on a chain of trust. The chain starts at the DNS root zone, which is trusted by DNS resolvers. Each level of the DNS hierarchy signs the level below it using cryptographic keys. When a DNS response is received, the resolver can verify these digital signatures all the way back to the trusted root. If any signature is invalid or missing, the response is rejected rather than trusted.

Residual Risk

I looked that the risk and these seam to the the main ones:

• DNSSEC does not encrypt DNS queries, so others can still see which domains you are looking up.
• It only protects domains that have DNSSEC enabled.
• It cannot stop users from visiting legitimate but malicious domains.
• If a user's computer or DNS resolver is compromised, DNSSEC cannot protect against that.

sequenceDiagram autonumber actor User participant Browser participant Resolver as DNS Resolver participant Root as Root DNS participant TLD as .com DNS participant Auth as Authoritative DNS participant Website as Web Server

---
config:
  #look: handDrawn
  #theme: neutral
---
sequenceDiagram
    autonumber
    actor User
    participant Resolver as DNS Resolver
    participant DNS as DNS Server
    participant Website

    rect rgb(230,242,255)
        Note over User,DNS: 1. DNS Request
        User->>Resolver: Lookup hanndoddi.com
        Resolver->>DNS: Request IP address
    end

    rect rgb(235,250,235)
        Note over Resolver,DNS: 2. DNSSEC Validation
        DNS-->>Resolver: IP address + Digital Signature
        Resolver->>Resolver: Verify signature
    end

    rect rgb(255,245,215)
        Note over Resolver,User: 3. Trusted Response
        Resolver-->>User: Verified IP address
    end

    rect rgb(250,230,250)
        Note over User,Website: 4. Connect
        User->>Website: Open website
    end

Exercises

After spending some time reading and researching, it was time to try the exercises.

TLS Handshake

To understand the TLS handshake, I first looked at how TLS 1.2 works and then briefly at TLS 1.3. I made a simple overview diagram to better understand the process before starting.

Next, I installed Wireshark and spent some time looking at the network traffic on my home network. I applied the filter host hanndoddi.com and used curl -v https://hanndoddi.com to capture a TLS handshake.

It was exciting to see the connection being established. First came the TCP three-way handshake, followed by the Client Hello message with (SNI=hanndoddi.com). In the Protocol column I could also see that the connection was using TLS 1.3.

I also enjoyed exploring the packet details. The lower pane displays the raw packet bytes in hexadecimal, while selecting different fields in the packet details highlights the corresponding bytes. This made it much easier to understand how the protocol is structured.

Inspecting the Client Hello packet, I found that curl advertised 31 supported cipher suites, together with information about supported key exchange methods, encryption algorithms, signature algorithms, and other TLS extensions. This is essentially my computer telling the server which cryptographic options it supports so they can negotiate a secure connection.

Looking at the Server Hello, I could see that the server selected the cipher suite:

TLS_AES_128_GCM_SHA256 (0x1301)

I also inspected the server certificate and the key exchange information included in the handshake. The certificate contains the server's public key and identity, allowing the client to verify that it is communicating with the correct server. The key exchange information is then used by the client and server to establish a shared secret, which is used to encrypt the remainder of the session.

After the handshake completed, the remaining packets were simply shown as Application Data. Although I could still see information such as the IP addresses, packet sizes, and timing, the actual HTTP requests and responses were encrypted and could no longer be read. That clearly demonstrates the purpose of TLS: anyone observing the network can see that a secure connection exists, but not the contents of the communication.

Seeing the handshake in Wireshark made TLS much easier to understand than simply reading about it, especially the point where the traffic changes from readable handshake messages to encrypted application data.

Port Scan & Firewall

I began by checking which ports were open by scanning the VM from my local machine using:

sudo nmap -sV <ip-address>

The scan revealed two open ports:

22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.16 (Ubuntu Linux; protocol 2.0)
5901/tcp open  vnc     VNC (protocol 3.8)

SSH is required for connecting to the VM over the terminal. The VNC service, on the other hand, is only needed for remote graphical access. Since I don't normally use the graphical desktop, I decided to block that port using the firewall to reduce the VM's exposed attack surface.

Firewall

Next I connected to the VM and used UFW (Uncomplicated Firewall) to check and configure it. Since I only needed SSH access, I configured the firewall to allow SSH while blocking VNC. First I checked the current firewall status:

sudo ufw status verbose

It turned out to be inactive and simply returned Status: inactive, so I ran these three commands:

sudo ufw allow ssh
sudo ufw deny 5901/tcp
sudo ufw enable

I ran the status command again, and it now looked like this:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
5901/tcp                   DENY IN     Anywhere
22/tcp                     ALLOW IN    Anywhere
5901/tcp (v6)              DENY IN     Anywhere (v6)
22/tcp (v6)                ALLOW IN    Anywhere (v6)

After adding the firewall rules, I scanned the VM again from my local machine.

This time only SSH was reachable, while the VNC service was no longer visible from the network. Nmap reported that the remaining ports were filtered, confirming that the firewall was blocking incoming connections as intended.

I also tried opening the VNC web interface in my browser after enabling the firewall. The page no longer loaded, confirming that the service was no longer reachable from the network.

Hide and Seek

I wanted to try to change my name to see if I could hide my user name first I tought it would be easy I'll just change my name:

sudo hostnamectl set-hostname <new-username>

That did change it but old one was still showing up on the nmap scan. Looking into it I found that automated cloud/lab deployments, cloud-init manages system configuration files at boot or network events. To prevent my configuration files from being reverted, I had to disable host entry management. The file was here:

sudo vi /etc/cloud/cloud.cfg

I change one like to true and commented out another line:

preserve_hostname: true
# - update_etc_hosts

I then tried nmap and old name was still showing up I then tried manually map it in hosts:

sudo vi /etc/hosts

This is what I had to change there:

127.0.1.1         <new-username> <new-username>
<ip-address>    <new-username>

I then ran these two comand to flush the cache and make the changes:

sudo systemctl restart systemd-resolved
sudo networkctl renew eth0

Then I ran nmap again and I was hidden.

It was strange when I ran it in the my local machine I did see the name.

If you want to find me I just change my student name to a random name so there is one student on the list that is not on the class list.