ZZEN9217 H6 O.S. Fundamentals for Security: VM platform notes

Important Kali, Kali2 or Parrot must be started before Windows XP, Windows 7 or Metasploitable2. This is because the script which starts Kali/Kali2/Parrot also creates the virtual network bridge used to link the latter virtual machines. Without the bridge the Windows and Metasploitable2 virtual network interface cannot be created.

Notes for 2023T3 edition

VM's available

Product	Start script	Comments
Kali	startkali	Originally-deployed version
Windows XP	startwin	Originally-deployed version, no patches or updates
Windows 7	startwinx7	Originally-deployed version, no patches or updates
Metasploitable2	startmeta2
Parrot Security	startparrot	Functional routing replacement for Kali and Kali2. I.e., either it or Kali/Kali2 are required to set up the networking for the Windows hosts or Metasploitable2. Kali's and Kali2's eth0 is Parrot's ens3, eth1 is ens4
Kali2	startkali2	New version (2023.2) for 2023T3

Start-up chain of actions

Virtual machines are run by qemu-system-x86_64.

User runs:

/usr/local/infrastructure/bin/startXYZ

Which uses:

sudo (/etc/sudoers.d/startXYZ)

To run (as root):

/usr/local/qemu_machines/startXYZ

Which runs does the necessary setup (including network interfaces), creates the temporary hard disk image, and then runs qemu-system-x86_64.

Notes regarding original implementation

• Testing on [AWS] nw-syd-vx1 using QEMU in emulation mode rather than hypervisor/KVM mode
• Then installed on vx0 (an out-of-warranty Dell R510) which is configured as a New World VLAB/login server, which is used as a testing platform, and which runs the VM's with QEMU in hypervisor/KVM mode
• Final (new) home is vx01, which was vx1 and then was corelli. Scripts and files remain unchanged
• Images and scripts in /usr/local/qemu_machines + /usr/local/infrastructure/bin/start(win|kali) + /etc/sudoers.d/start(win|kali)
• Installed qemu-system-x86 and bridge-utils packages
• startkali: starts Kali Linux, includes second interface (eth1) for link to Windows XP host established via up/down scripts for QEMU which set up a bridge and join eth1 (tap device) to the bridge. Due to the down script running as the user rather than root (due to "-runas" in qemu-system-x86_64 invocation) the bridge created by the up script cannot be removed
• startwin: starts Windows XP, up/down scripts link network tap device to bridge mentioned above
• Kali Linux primary interface (eth0) uses DHCP and gets the QEMU user-network address of 10.0.2.15/24. This is also Kali's default route
• Kali Linux second interface (eth1) has a static IP address of 192.168.1.1/24
• Windows XP primary interface has a static address of 192.168.1.2/24. Windows XP has no default route and no DNS servers
• Kali's eth1 and the Windows XP primary ethernet interface are connected together via TAP interfaces on a private bridge named "br<username>" (e.g., "brplinich"). See brctl show

Kali2 host testing accounts

Account name	Password
kali	kali

Kali host testing accounts

Account name	Password
root	password
user	user

Parrot host testing accounts

Account name	Password
user	user

Correspondence

On 30 Aug 2023, at 11:45 pm, Arash Shaghaghi <a.shaghaghi@unsw.edu.au> wrote:

Hi Peter,

Do I have access to terminate any active session that may be limiting a user's connection to the server?
It seems one of our students is locked out and unable to reconnect.

Thank you.

Arash

Sent from mobile.
From: Alex Garin <a.garin@student.unsw.edu.au>
Sent: Wednesday, August 30, 2023 23:41
To: Arash Shaghaghi <a.shaghaghi@unsw.edu.au>
Subject: Re: Week 1 Lab

Sorry Arash,

I was able to get all the way into Kali at first but I logged out of the VIM server and can't get back in.

Thanks again
Alex

Reply from Peter:

Hi,

Firstly, it is unclear to me what a “VIM” server is. I might wildly speculate that it’s vx01, where the VM’s for the course run.

Second, the student’s problem description is poor. What are they trying to log in to exactly? What are they doing? Do they get an error message? Do they get a timeout?

If they are unable to log in to vx01, then this probably has nothing to do with VM’s and there’s nothing you can do to fix it for them. vx01, and all the other VLAB servers, are self-cleaning and users can practically always log in using their zID and zPass. It is possible for a student to render their account unusable — such as by messing up either the .xession or .bash-profile files in their home directory — but such things are rare. In any case, if there’s such an account problem, ss@cse.unsw.edu.au is the best first stop for a solution.

The most common such problem we see is that the student’s zID or zPass are wrong or have expired. They basically would get a “wrong password” message or similar when they try to log in. They’d have to talk to UNSW IT’s service desk people to fix these sorts of problems. I’m mentioning this for completeness as it doesn’t sound like the problem here.

Also, VLAB sessions (including vx01) expire after a period of inactivity and get terminated and cleaned up automatically. This would include and VM’s that were running.

If the student is able to log in to vx01 and it’s a particular VM they’re having trouble with, all the VM’s have a GUI and closing the GUI should make the VM terminate and then be able to restarted. If they have somehow disconnected from vx01 and the automatic session timeout hasn’t cleaned up their old session, then they can log in again and use command line tools, such as “kill”, to kill off the previous session’s VM’s (including kali).

I’ll mention that if the student clobbered kali then they’d probably need to stop all the other VM’s they were running, then restart kali (which sets up the virtual network) and then restart the other VM’s.

Finally, when you mention such problems in an email to me or SS, please include the student’s zID so we can do a preliminary check ourselves.

Peter