Lab 5 – Laboratory: SSH, HTTP, and Firewall
Correction elements for this lab are available in the exercise repository: 👉 module-17 – Corrections
This lab uses up to 3 network cards per VM. For a detailed explanation of card types (NAT, Internal Network, Host-Only, Bridged) and their VMware equivalents, see: 👉 Module 15 - Bonus: VirtualBox vs VMware Network Cards
Work in teams of two
| Name | |
|---|---|
| Student 1 | ........................ |
| Student 2 | ........................ |
Objectives
This lab aims to apply the knowledge acquired on the protocols and services studied so far (SSH, HTTP, Firewall) in a Linux environment.
Required Environment
Hypervisor
- VirtualBox (or VMware Workstation / VMware Player)
Virtual Machines to Create
| Machine | Operating System | RAM | Disk | CPU | Network Interfaces |
|---|---|---|---|---|---|
| srvGateway | Ubuntu Server 24.04 LTS (or 22.04 LTS) | 1 GB minimum | 20 GB | 1 vCPU | 3 interfaces: NAT + Internal Network lan + Internal Network clientnet |
| srvSSH | Ubuntu Server 24.04 LTS (or 22.04 LTS) | 1 GB minimum | 20 GB | 1 vCPU | 1 interface: Internal Network lan |
| srvWEB | Ubuntu Server 24.04 LTS (or 22.04 LTS) | 1 GB minimum | 20 GB | 1 vCPU | 1 interface: Internal Network lan |
| Client | Ubuntu Server 24.04 LTS (or 22.04 LTS) | 1 GB minimum | 20 GB | 1 vCPU | 1 interface: Internal Network clientnet |
- srvGateway needs 3 network cards:
- Adapter 1: NAT (Internet access)
- Adapter 2: Internal Network →
lan(LAN network10.11.12.0/24) - Adapter 3: Internal Network →
clientnet(Client network20.21.22.0/30)
- srvSSH and srvWEB: Internal Network →
lan - Client: Internal Network →
clientnet
Required Software on VMs
| Machine | Software to Install |
|---|---|
| srvGateway | iptables, net-tools |
| srvSSH | openssh-server |
| srvWEB | apache2, openssl, certbot (optional) |
| Client | openssh-client, curl, wget |
IP routing (ip_forward) must be enabled on srvGateway for traffic to flow between networks.
The other machines (srvSSH, srvWEB, Client) must have srvGateway as the default gateway.
Network Topology
Description of Machines
| Machine | Role | Interface(s) |
|---|---|---|
| srvGateway | Routing and Internet gateway | Interface 1: NAT (Internet) |
Interface 2: 10.11.12.1/24 (LAN) | ||
Interface 3: 20.21.22.1/30 (Client) | ||
| srvWEB | Apache web server | 10.11.12.150/24 |
| srvSSH | SSH server | 10.11.12.100/24 |
| Client | Client machine | 20.21.22.2/30 |
Expected Connectivity
srvGatewayhas Internet access- The client,
srvWEB, andsrvSSHcan access the Internet throughsrvGateway - SSH, HTTP, and HTTPS traffic is allowed on
srvGateway
Failure to adhere to the topology or providing screenshots that do not match the instructions will result in a point penalty.
Part 1 – Configuration of Routing and Connection Sharing (40 points)
1.1 – Configure Static IP Addresses
Configure static IP addresses on each of the four machines according to the topology.
Take a screenshot of the interfaces for each machine.
1.2 – Enable Permanent Routing on srvGateway
Enable routing (IP forwarding) permanently on srvGateway.
Insert the screenshot of the permanent routing activation.
1.3 – Configure Internet Connection Sharing on srvGateway
Add iptables rules to:
a) Allow outgoing traffic from the LAN, relayed by srvGateway
Screenshot required.
b) Allow only SSH, HTTP, HTTPS, and ICMP traffic for other machines
Screenshot required.
c) Enable MASQUERADE
Screenshot required.
d) Test Internet Connection
Test the Internet connection from the client, srvSSH, and srvWEB.
Screenshot required.
Part 2 – Configuration of Services (40 points)
2.1 – Configure an Apache Web Server on srvWEB
a) Create Two Virtual Hosts
Create two virtual hosts on srvWEB:
| Virtual Host | Domain Name |
|---|---|
| Site 1 | www.test.local |
| Site 2 | www.labo.local |
Screenshot required.
b) HTML Pages with Student Names
Insert HTML pages with the names of the team students.
Screenshot required.
c) Configuration Files and Web Pages
Insert screenshots of the configuration files and displayed web pages.
2.2 – Configure Secure Access via HTTPS
a) Install SSL Certificates
Install SSL certificates for the two virtual hosts.
Concerned Virtual Hosts:
- www.test.local → self-signed certificate
- www.labo.local → self-signed certificate
Screenshot required: certificates and HTTPS pages.
2.3 – Restrict Access to srvWEB from the Client
a) Block Access from 20.21.22.2
Modify the configuration to block the address 20.21.22.2.
Screenshot required.
b) Test with curl
Test with curl and insert the screenshot of the access denial.
Part 3 – Configuration of Remote Access (20 points)
3.1 – Configure an SSH Server on srvSSH
a) Create the user bob
Create a user bob with /home/bob and /bin/bash.
Required Screenshots:
- Output of
ss -tan - Output of
tail /etc/passwd
3.2 – Configure a Local SSH Redirection (Tunnel)
Use an SSH tunnel so the client can access www.labo.local via srvSSH.
Principle of the SSH Tunnel:
Required Screenshots:
- SSH tunnel command
- Successful access to
www.labo.localfrom the client via the tunnel
Recap of Topology and Flows
Evaluation Grid
| Part | Criteria | Points |
|---|---|---|
| Part 1 | Configuration of routing and connection sharing | 40 |
| Configuration of static IP addresses + screenshots | 10 | |
| Activation of permanent routing | 5 | |
| iptables rules (SSH, HTTP, HTTPS, ICMP) | 10 | |
| MASQUERADE | 5 | |
| Internet connection tests (client, srvSSH, srvWEB) | 10 | |
| Part 2 | Configuration of services | 40 |
| Apache virtual hosts (www.test.local, www.labo.local) | 10 | |
| HTML pages with student names | 5 | |
| Configuration files + displayed pages | 5 | |
| SSL certificates and HTTPS | 10 | |
| Access restriction (blocking 20.21.22.2) | 5 | |
| curl test + screenshot of access denial | 5 | |
| Part 3 | Configuration of remote access | 20 |
| User bob + screenshots (ss -tan, /etc/passwd) | 10 | |
| SSH tunnel + access to www.labo.local | 10 | |
| Total | 100 |
Lab created on: February 2025
BONUS MODULE – Understanding the TLS Handshake (simplified)
The goal here is to explain, in very simple terms, what happens when you type an address in HTTPS.
A “module bonus” version (outside of this lab) is available here: Module 15 – Bonus: TLS Handshake (simplified).
1) Before TLS: the TCP “handshake” (SYN / SYN‑ACK / ACK)
Before talking about encryption (TLS), you must first establish the network connection. For HTTPS, it is generally TCP on port 443.
TCP uses a handshake in 3 messages:
- SYN: "Hello, I want to talk to you, are you there?"
- SYN‑ACK: "Yes, I am here, and I received your SYN. Can you hear me?"
- ACK: "Yes, I hear you, I received your message. We can start."
ACK = Acknowledgment (it just means: "I received").
👉 Important: this TCP handshake does not encrypt anything. It only serves to say: "the connection is ready."
2) Next: the TLS handshake (to secure the conversation)
Once TCP is established, we launch TLS (which makes HTTP → HTTPS).
Think of TLS as: agreeing on a lock, verifying the server's identity, then speaking in a secret language.
Here is the general idea (without going into cryptographic details):
- ClientHello (client → server):
- "Hello, I can do TLS, here are the versions and algorithms I support."
- ServerHello (server → client):
- "OK, we choose this TLS version and these algorithms."
- The server also sends its certificate (its "ID card").
- Certificate Verification (client side):
- The client verifies that the certificate is valid, matches the site name, and is signed by a known authority (or manually accepted if self-signed).
- Creation of a Shared Secret:
- Client and server set up keys to encrypt (often via a key exchange like Diffie‑Hellman).
- From there, they can create session keys.
- Finished (from both sides):
- They send each other a final message to confirm: "we have the same keys, we are ready."
✅ After that, everything that follows is encrypted: full URLs, contents, passwords, cookies, etc.
3) Short Summary “in One Sentence”
- TCP (SYN/SYN‑ACK/ACK): we open the door (connection)
- TLS (ClientHello… Finished): we put a lock and verify identity (security)
- HTTP/HTTPS: this is what we say once the door is open and the lock is in place
- In HTTP, you will see the content (often readable).
- In HTTPS, you will mostly see the TLS handshake followed by encrypted packets (unreadable content).