Session 2: Internet Security¶

The Toolkit¶

For each security mechanism, I apply three questions from the lecture: 1. What threat does it address? — which adversary goal is it designed to stop? 2. What’s the trust model? — what does it assume, and who/what are we trusting? 3. What’s the residual risk? — what’s left exposed even when it works perfectly?

Six Systems Analysis¶

PGP — End-to-End Email Security¶


Threat addressed	Eavesdropping and tampering on email in transit. Email passes through many servers (ISP, provider, recipient’s server) — any of them can read or modify it. PGP encrypts the message body so only the intended recipient can read it, and signs it so tampering is detectable.
Trust model	Web of trust — users sign each other’s public keys to vouch for identity. There is no central authority; trust is decentralized and transitive. You trust a key if someone you already trust has signed it.
Residual risk	Metadata is not protected — sender, recipient, subject, and timing remain visible. Endpoint compromise defeats everything: if the recipient’s device is hacked, the decrypted message is exposed. Key discovery is awkward; most users never verify fingerprints in practice.

SSH — Secure Remote Access¶


Threat addressed	Eavesdropping and impersonation on remote login sessions. Without SSH, credentials and commands travel in plaintext (as with Telnet). SSH also prevents a man-in-the-middle from injecting commands into the session.
Trust model	Trust on first use (TOFU) for host keys — the first time you connect, you accept the server’s fingerprint and it is stored locally. On subsequent connections, a mismatch raises an alarm. For user authentication, you trust the private key holder.
Residual risk	TOFU means the first connection is unverified — an attacker who intercepts that first connection can silently substitute their own key. Compromised private keys grant full access. Port forwarding can be abused to tunnel other traffic through an SSH session.

VPN / IPsec — Network-Layer Tunneling¶


Threat addressed	Eavesdropping and traffic manipulation at the network layer — especially over untrusted networks (public WiFi, ISP links between offices). IPsec encrypts and authenticates entire IP packets, making the path between two endpoints look like a private wire.
Trust model	Both endpoints must share credentials — either a pre-shared key or certificates from a PKI. The VPN gateway is fully trusted: all traffic passes through it in plaintext on the protected side.
Residual risk	The VPN gateway itself is a high-value target — compromise it and you see all traffic. Traffic metadata (timing, volume, source/destination of the tunnel endpoints) remains visible. VPNs do not protect against threats already inside the tunnel, such as malware on the client.

MACsec — Link-Layer Encryption¶


Threat addressed	Eavesdropping and tampering on a single physical network segment (Ethernet). An attacker with physical access to a switch port or cable can capture all traffic on that segment. MACsec encrypts frames between directly connected devices before they leave the wire.
Trust model	Devices on the same link segment trust each other after mutual authentication using 802.1X or pre-shared keys. Trust is strictly hop-by-hop — each link is independently secured; MACsec does not protect traffic end-to-end across routers.
Residual risk	Only the local link is protected — traffic is decrypted at each switch and re-encrypted for the next hop. A compromised switch sees all traffic in plaintext. MACsec does not address threats at higher layers (application, transport). Rarely deployed outside data centers and carrier networks.

DNS Security — DNSSEC & DNS Spoofing¶


Threat addressed	DNS spoofing (cache poisoning) — an attacker injects false DNS records to redirect users to malicious servers. Without DNSSEC, DNS responses carry no proof of authenticity. A poisoned resolver will send users to the wrong IP address even if the connection later uses TLS.
Trust model	Hierarchical chain of trust rooted at ICANN’s root zone. Each zone signs its records; the parent zone signs the child zone’s public key. Your resolver trusts the root zone and validates signatures down the chain.
Residual risk	DNSSEC proves authenticity but not confidentiality — queries and responses are still visible in plaintext (DNS over HTTPS / DNS over TLS address this separately). DNSSEC deployment is incomplete; many domains are unsigned. Zone enumeration attacks (NSEC walking) can enumerate all hostnames in a signed zone.

IDS / IPS — Intrusion Detection vs. Prevention¶


Threat addressed	Attacks that pass through the perimeter — exploitation attempts, malware communication, lateral movement. A firewall controls access by rules; an IDS/IPS watches traffic patterns and known attack signatures to catch threats that firewall rules alone cannot block.
Trust model	Trusts that its signature database and behavioral models accurately represent malicious activity. Typically positioned to see all traffic (inline for IPS, out-of-band for IDS). The system itself must be hardened — a compromised IDS provides false confidence.
Residual risk	IDS detects but cannot stop attacks — only alerts. IPS can block but also generates false positives, potentially disrupting legitimate traffic. Encrypted traffic is a blind spot unless TLS inspection is deployed (which introduces its own trust issues). Zero-day attacks with no known signature bypass both.

Exercise 1: TLS Handshake Trace¶

Method¶

Used openssl s_client to connect to github.com and capture the TLS handshake details from the Ubuntu VM.

openssl s_client -connect github.com:443 </dev/null 2>&1 | head -40
openssl s_client -connect github.com:443 </dev/null 2>&1 | grep -E "Protocol|Cipher|TLS"

Results¶

Certificate chain:

depth=2 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root E46
depth=1 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36
depth=0 CN=github.com
Verification: OK

Certificate chain:
 0 s:CN = github.com
   i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36
   a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA256
   v:NotBefore: Jul 3 00:00:00 2026 GMT; NotAfter: Sep 30 23:59:59 2026 GMT

Cipher suite:

New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256

Analysis¶

What the handshake established:

Property	Value
Protocol	TLS 1.3
Cipher suite	TLS_AES_128_GCM_SHA256
Key exchange	Ephemeral Diffie-Hellman (built into TLS 1.3)
Server certificate	`github.com` — EC key, 256-bit
Certificate issuer	Sectigo Public Server Authentication CA DV E36
Root CA	Sectigo Public Server Authentication Root E46
Validity	Jul 3 – Sep 30 2026
Verification	OK — chain traces to a trusted root CA

What an observer on the network CAN see: - Source and destination IP addresses - Destination port (443) - Server name via SNI — github.com (sent in plaintext during handshake) - Certificate details: issuer, subject, validity dates - Volume and timing of traffic

What an observer CANNOT see: - HTTP request path, headers, or body - Cookies, session tokens, passwords - Response content - Which specific page or repository was accessed

Forward secrecy: TLS 1.3 always uses ephemeral Diffie-Hellman key exchange. Even if github.com’s private key is stolen in the future, this session cannot be decrypted retroactively.

Exercise 2: Port Scan & Firewall¶

Step 1 — Identify running services¶

ss -tulnp

Output:

tcp   LISTEN  0.0.0.0:22    sshd — SSH
tcp   LISTEN  0.0.0.0:5901  Xtigervnc — VNC remote desktop
tcp   LISTEN  0.0.0.0:6081  noVNC — browser-based VNC client
tcp   LISTEN  127.0.0.1:631 CUPS — printing (localhost only, not exposed)
udp   UNCONN  0.0.0.0:5353  mDNS (Avahi)

Port 631 (printing) and DNS ports are localhost-only — not exposed to the network. Ports 22, 5901, and 6081 are listening on 0.0.0.0 — reachable from anywhere on the network.

Step 2 — Port scan before firewall configuration¶

nmap -sV 192.168.80.104

Results (before):

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.16
5901/tcp open  vnc     VNC (protocol 3.8)

What this reveals to an attacker: - Port 22 (SSH): Server version exposed — OpenSSH 9.6p1. An attacker knows the exact software version and can look up known vulnerabilities. - Port 5901 (VNC): Remote desktop service exposed — typically weaker authentication than SSH, no encryption by default.

Step 2 — Configure UFW firewall¶

sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.80.0/24 to any port 22
sudo ufw allow from 192.168.80.0/24 to any port 5901
sudo ufw status verbose

Firewall rules after configuration:

Status: active
Default: deny (incoming), allow (outgoing)

To                         Action      From
--                         ------      ----
22                         ALLOW IN    192.168.80.0/24
5901                       ALLOW IN    192.168.80.0/24

Both services are now restricted to the WireGuard VPN subnet (192.168.80.0/24) only.

Step 3 — Verify firewall rules¶

A scan from outside the VPN subnet would show all ports as filtered — no services visible, no version information exposed. Scanning from within the VPN still shows the ports open because the firewall allows the 192.168.80.0/24 subnet, and the VM itself is on that subnet.

Analysis¶

What changed:

	Before firewall	After firewall
SSH (22)	Open to the entire internet	VPN subnet only
VNC (5901)	Open to the entire internet	VPN subnet only
External attacker sees	Service names and versions	All ports filtered — host appears dark

Applying the toolkit to the firewall:


Threat addressed	Unauthorized access and reconnaissance — an attacker cannot exploit or even identify a service they cannot reach. Reduces the attack surface to zero for anyone outside the VPN.
Trust model	The WireGuard VPN subnet (`192.168.80.0/24`) is trusted; all other sources are untrusted by default. This assumes the VPN itself is secure — which is enforced by WireGuard’s cryptographic authentication.
Residual risk	Anyone already authenticated to the VPN can still reach both services. The firewall inspects addresses, not content — a valid connection carrying malicious commands passes through. Misconfigured rules (such as accidentally allowing `0.0.0.0/0`) could silently re-expose services.

Key Takeaways¶

Security is layered — no single mechanism protects everything. PGP protects content but not metadata; a firewall blocks access but not content; TLS encrypts traffic but not endpoints.
Every mechanism has a trust model — you are always trusting something: a CA, a VPN gateway, a key fingerprint. Understanding what you trust is as important as understanding what is protected.
Residual risk is always present — even a perfectly configured system leaves something exposed. The goal is to reduce risk to an acceptable level, not eliminate it entirely.
Practical tools used: openssl for TLS inspection, ss and nmap for network reconnaissance, ufw for host-based firewalling.

AI Assistance¶

I used Claude AI (claude-sonnet-4-6) as a learning assistant throughout this session. I ran all commands myself on my Ubuntu VM via SSH over WireGuard VPN. Key prompts I wrote: provided the homework requirements and lecture PDF, ran all terminal commands (openssl, nmap, ufw) on my own VM, and asked for explanations of the results.

Claude helped me structure the six-system analysis using the threat/trust/risk toolkit from the lecture, interpret the TLS handshake certificate chain and cipher suite output, and guide the UFW firewall configuration step by step. All practical outputs are real results from my own VM (ff-cs-sedat-yalcin, 192.168.80.104).