Operating Systems Module

System Planning and Distribution Selection

24/10/2025

System Architecture Diagram

Distribution Selection Justification

I chose to use the ARM64 version of Ubuntu Server. This is widely adopted in enterprise for good reason, as it offers a balance of stability and usability. This is important as it would be my first time configuring a Linux server. Ubuntu Server is easy to use, offering strong documentation and simple package management for additional software that may be needed for future tasks of the coursework.

This is in comparison to CentOS Stream, another server distribution which requires more manual configuration for installing software packages. Another distribution I considered was Debian, a popular and stable operating system. However, I decided against using Debian as it is less up-to-date, as it has a slower release cycle. In addition, Debian requires more configuration for security, while Ubuntu Server is more automated, speeding up the time it will take to set up my VM.

Ubuntu Server is also clearly the best option due to its simple and guided installation process, which is intuitive and requires less manual setup and knowledge to get started. It is designed to be accessible for new Linux users, with beginner-friendly documentation and simple package management. This is in contrast to CentOS Stream or Debian, which require more configuration knowledge with their more complex setup processes.

These distributions are more geared towards experienced server administrators, and require more learning than would be possible during the timescale of the coursework.

Workstation Configuration

My workstation is a MacBook Pro with the macOS Tahoe (version 26) operating system installed. This is my primary device, and is good for virtualisation due to the Apple Silicon ARM architecture and Apple’s virtualisation and hypervisor frameworks. Due to said CPU architecture, the version of Ubuntu Server I have to install will have to be the ARM64 build due to the performance issues virtualising another CPU architecture would introduce.

macOS is part of the UNIX family of operating systems, which has many similarities with Linux. This reduces compatibility issues as a lot of the kernel level features are the same, meaning the virtualised server will be more stable and performant. UNIX-based hosts such as macOS also come with Linux tools such as built-in SSH via the Terminal, which means connecting to the server will be easier, not requiring the installation of PuTTY like on Windows hosts.

Network Configuration

When configuring the network connection between my server VM and my workstation, I will use the "Bridged Adapter" option within VirtualBox to ensure the server VM is hosted on the same network, and with the same subnet mask. The bridged option connects the guest network interface to the host's, appearing as a seperate device on the local network. This allows connection to the guest machine via SSH without requiring port forwarding or NAT to be configured. This means that the server VM can be connected to from the local machine with a local subnet IP.

System Specifications

The specifications of my server VM are as follows:

uname: Linux
Total Memory: 1954MB
Free Memory (idle): 1579MB
Buff/Cache Memory: 216MB

df -h:


            Filesystem      Size  Used Avail Use% Mounted on
tmpfs           196M 1004K  195M   1% /run
efivarfs        256K   16K  241K   6% /sys/firmware/efi/efivars
/dev/sda2        24G  2.8G   20G  13% /
tmpfs           978M     0  978M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda1       1.1G  6.4M  1.1G   1% /boot/efi
tmpfs           196M   12K  196M   1% /run/user/1000

ip addr:


            1: lo:  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
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp0s8:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:a5:20:1c brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.101/22 metric 100 brd 192.168.7.255 scope global dynamic enp0s8
       valid_lft 13853sec preferred_lft 13853sec
    inet6 fd94:238e:7224:284b:a00:27ff:fea5:201c/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 1743sec preferred_lft 1743sec
    inet6 fd79:f176:bc9f:1:a00:27ff:fea5:201c/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591731sec preferred_lft 604531sec
    inet6 fe80::a00:27ff:fea5:201c/64 scope link 
       valid_lft forever preferred_lft forever

lsb_release: No LSB modules are available.

I used the uname, free, df -h, ip addr, and lsb_release commands to provide the above system specifications.

Security Planning and Testing Methodology

31/10/2025 🎃

Performance Testing Plan

In my performance testing plan, I will monitor my server VM's metrics to ensure system stability, and collect data for capacity planning.

For remote monitoring, I will use the htop tool to view processes running, iostat to see CPU statistics, netstat to view current network connections and bandwidth usage, and vmstat to see how much virtual memory is being used, so I can increase the "physical" memory if required.

Key performance indicators (KPIs) I will track will include:

CPU Utilisation
Memory Usage
Disk I/O
Network Throughput

From these tests, I would like to determine how certain stresses affect response time through SSH. I could use stress testing tools such as stress-ng and sysbench.

Security Configuration Checklist

I will edit the SSH configuration file editing various settings to ensure the security of my VM instance. While the risk of attack is low as it is on my own local network, security measures should still be in place as a good practice.

Using key based authentication instead of passwords, as these cannot be as easily stolen/brute forced.
Installing "Fail2ban", this is a tool that bans IP addresses that show malicious behaviours like too many password attempts.
Configuring a firewall using the ufw command, only allowing necessary ports for SSH and HTTP(S).
Enable unattended-upgrades to automatically install security updates.
I could scan for open ports that don't need to be open, to tighten security.

Security Threat Model

My threat model will identify three security threats and propose mitigation strategies for them.

Unauthorised Access: The mitigation for this would be to use strong passwords, or to use the key-based authentication that I mentioned above. This would prevent access to the server VM from bad actors.
Malware/Ransomware: If malware is unknowingly installed on the system, data could be stolen or the system could cease functioning, meaning that my coursework would be disrupted. Mitigation for this includes enabling unattended-upgrades (as mentioned above), and potentially installing an antivirus scanner. I will also make regular backups of the virtual machine, saving its state at each stage so that I can rollback at any time.
Denial of Service (DoS) Attacks: Fail2ban and firewall configuration can be used to prevent an attacker flooding my system with malicious traffic which would prevent me from working. In addition, I could configure rate limiting preventing an influx of requests fron a single IP address.