OPS105 Winter 2025 Project

What's new

Initial project spec

  1. Install Kali (Graphical Desktop) in a VirtualBox VM.
  2. Change network settings of VMs created during first six weeks from CIDR/30 (glue network) to CIDR/29 (smallest multi-host network).
  3. Add Kali VirtualBox VM as a node within the CIDR/29 (smallest multi-host) network. This means your internal network will comprise of three VMs: two nodes and one gateway.
  4. Configure Kali to:
    • run in full screen after it boots and logs in to the desktop.
    • only have Internet access when gateway VM is up and running.
  5. Go Pro: Configure gateway to run Minimal Ubuntu Server LTS 24.04 in VirtualBox stealth mode. Stealth mode has no graphical window on the host operating system (Windows/macOS/Linux). For stealth mode: besides VirtualBox GUI interface, the startup and shutdown of virtual machines can also be managed by VirtualBox command line utilities.

OpenSSH Server and MySeneca user account

  1. Install OpenSSH server on your Gateway.
  2. Configure OpenSSH to disallow ssh connections from user root.
  3. On all VMs create an unpriviledged (non-root) user to match your MySeneca username.
  4. Verify this MySeneca-named user can login to your gateway from the two node graphical desktops: Ubuntu and Kali.
  5. IMPORTANT: Verify MySeneca-named user can login to matrix.senecapolytechnic.ca when Student VPN is running on host operating system.
  6. Go Pro: Set MySeneca-named user to login to gateway (Minimal Ubuntu Server LTS 24.04) without a password (HINT: research how to setup password-less access with ssh).

Using sudo

  • Install sudo package.
  • Configure your MySeneca-named user to run administrative commands using sudo. Login as your MySeneca-named user and using sudo:
    • bring packages up-to-date
    • complete the other privilege related tasks below
  • Understand why using sudo is better than using su and su -.

File sharing network

  1. Create a file sharing server for users on this network. Create three users: jack, jill, and eve in addition to your MySeneca-named user (so there are four users, not including root, on all three VMs in this network.


  2. Create three groups: attack, defend, and staff which are team names used in attack, defend, and staff strategies commonly found at capture the flag events. The MySeneca-named user is a member in all three groups. Users jack, jill, and eve each belong to two groups: their own and their team (attack, defend, or staff). User jack is a member of groups: jack and attack. User jill is a member of groups: jill and defend. User eve a member of groups: eve and staff. MySeneca-named user is a member of MySeneca-named group and a member of groups: attack, defend, and staff.


  3. Login as each user on all three VMs. Configure ssh server on gateway so users: jack, jill, eve, and MySeneca-named user can upload files to and download files from the /public directory on gateway.


  4. Login as jill on the gateway and try to read from and write to files that users jack and eve created in the /public directory on the gateway. Similarly login to gateway as eve, jack, and as MySeneca-named user and try to read from and write to files that the others created in the /public directory.


  5. On gateway verify that users jack, jill, eve, and MySeneca-named user can meet these requirements:


    • Example: jill can read but not write to /public/jack.txt as the file is owned by jack. Users jill and jack can read from (but not write to) each other's files. While they may be able to read from each other's files, they cannot write to those same files as those files would be owned by the other. Both users jack and jill do not want user eve to either read from or write to any of their files. User eve, however, wants to read from and write to any file owned by either jill or jack.


    • Example: jack can write to but not read from bob's /public/jill.txt. In this example they can write to some of the other's files. Yet they cannot read or delete from those files as those files are owned by the other. As described before, users jill and jack allow files to be shared with each other but neither want eve to read from or write to any of their files.


    • User eve will try any means to access files created by others on the server. Configure the file sharing gateway and /public directory to not allow user eve to either read from or to write to any file not owed by user eve. This means user eve can only read and write to files that were created by user eve.


    • As the MySeneca named user is a member in all groups: attack, defend, and staff, that MySeneca named user has read and write access to files that groups attack, defend, and staff permit.


    • Users jill, jack, and MySeneca named user cannot change permissions of files not owned by them. Example: if file /public/jill.txt is owned by jill then neither jack nor MySeneca named user can change the permissions of bob's /public/jill.txt.


  6. Go Pro: Complete the lab on Bash scripting. Make a copy of that script to upload-file.bash. Modify the newly created script to do the following when upload-file.bash is called:

    • without arguments: display a usage message describing how to call the script and quit.
    • called with one argument that is not an existing file: display an error message using the given non-file argument and quit.
    • called with one argument that is an existing file copy that file to /public directory on gateway.
    • called with multiple arguments some of which are files: copy those that are files to /public but show error messages for those that are not files.
    • called with multiple arguments all of which are files: copy all files to /public.

    Configure your login shell so $HOME/bin is in the environment variable $PATH when each user logs in. Place upload-file.bash in $HOME/bin of each user on Ubuntu and Kali VMs. Modify upload-file.bash to personalize it for that user. For example: after user jack has uploaded a file that is to be shared by user jill and not user eve, modify the script upload-file.bash in alice's $HOME/bin to verify that the permissions were set correctly and warn user jack if it isn't.

Tips

Kali

  • TIP #1: When creating your Kali VM, give it at least 2048 MB memory, 2 virtual CPUs, and 32GB of disk space.


  • TIP #2: When running gateway in stealth mode from the command line, you need a VirtualBox command to start it up, however, shutting gateway down should be done from within the VM itself. Try to avoid shutting down from a VirtualBox command or the VirtualBox graphical application on your Windows/macOS/Linux desktop. In other words, this means you need to ssh in to the gateway from Windows or Ubuntu or Kali before you can shut the gateway down.

End of project spec

Last Updated: 2025-Feb-18 Tue 14:54