NETSEC VPN Client Setup and Remote Access

Prerequisites

Transfer your instructor provided *.pub public and *.key private key files into the host that will connect as a Wireguard client
Instructor will provide your peer ip address, username, temporary password, and server public key for remote host access

Install wireguard package using: $ sudo apt-get install wireguard
Once you have your credentials, setup VPN client in Kali
- Create the environment variables that the script below will use by replacing <PATH_TO_USERNAME_KEY_FILE> and <PATH_TO_USERNAME_PUBLIC_KEY_FILE> with the paths to server's *.pub public and client's *.key private key files, and use the IP address the instructor provided for XYZ
```
CLIENTKEY=$(cat <PATH_TO_USERNAME_KEY_FILE>)
SERVERPUBKEY=$(cat <PATH_TO_SHIKRA_PUBLIC_KEY_FILE>)
export IPADDR="172.16.1.XYZ/32"
```
- Run the script below as root as it will create the /etc/wireguard/wg0.conf file
```
# umask u=rwx,go= && cat > /etc/wireguard/wg0.conf << EOF
[Interface]
Address = $IPADDR
PrivateKey = $CLIENTKEY

[Peer]
PublicKey = $SERVERPUBKEY
Endpoint = 128.220.249.5:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
EOF
```
Bring the VPN up and down using the corresponding commands below:
```
$ sudo wg-quick up wg0
$ sudo wg-quick down wg0
```
If DNS is not passing through to 172.16.0.10, you can use /etc/hosts to manually create FQDN entries for *.netsec.isi.jhu.edu hosts that you will use frequently

Connect to the NETSEC VPN
Remotely log in to one of the NETSEC hosts (e.g., attack2) via ssh with your username and temporary password. When prompted to change it, provide a new password that will be used for all subsequent logins. Please make sure to use: $ ssh attack2.netsec.isi.jhu.edu and do not use $ ssh <USERNAME>@attack2.netsec.isi.jhu.edu on the first login. If you do, it tries to login with a local account that will not exist.
For IP addresses to resolve, you need to make entries for individual hosts on netsec.isi.jhu.edu in /etc/hosts from your local VM or setup a localhost resolver (see here).
If you are lazy, from your VM, run $ xhost +localhost (see https://wiki.archlinux.org/title/Xhost), otherwise, you can likely do the xauth details in the next session
SSH into the desired system using the -X option for X11 forwarding. E.g., $ ssh -X ctf1.netsec.isi.jhu.edu. If you did not setup DNS, you will have to use the actual IP address for the host.
From the remote SSH session, invoke the application that you would like to run locally with X11 forwarding (e.g., wireshark), and you should have the application open locally on your system via X11

Generate a MIT_MAGIC_COOKIE-1 by running on VM: $ mcookie
Get hash by running on VM: $ xauth list
Share cookie with remote host's X11 server by running (on remote host): $ xauth add attack/unix$DISPLAY .