# Azure Malware Lab: REMnux Template First things first - make sure you've got those snapshots of your OS sorted before we jump into setting this template up. >[!check] >This machine should be connected to the _sky_net_ vNet to enable internet connectivity. While our [[Azure Malware Lab Flare]] template is doing its thing, let's get cracking on our REMnux template. You'll need to connect using the public IP you've been assigned. (Same deal as before - JIT access is the way to go, but if you're not keen on the licence costs, just pop a rule in the NSG attached to the VM). Once you've got your NSG access sorted and opened up an SSH port, head to Connect and pick native SSH. You'll need to find where you stored that SSH private key (PEM file) and grab the SSH command they give you - this is your ticket into the VM. Fire up PowerShell, Windows Terminal, or if you're on Mac OS or Linux, just open Terminal and punch in your SSH command. It'll look something like this: `ssh -i C:\Users\gr00t\.ssh\grootnux.pem [email protected]` When prompted to continue connecting type in `Yes` to accept the fingerprint. Right, you're in your Ubuntu machine! Hang on though - wasn't this supposed to be REMnux? It will be, but we've got some setting up to do first. Let's start by downloading the REMnux image: ```bash wget https://REMnux.org/remnux-cli ``` Better check that SHA256 hash to make sure we've got the real deal: ```bash sha256sum remnux-cli ``` At the time of writing, you're looking for this hash: `c8c6d6830cfeb48c9ada2b49c76523c8637d95dc41d00aac345282fb47021f8e` - but do yourself a favour and check the official hash at [REMnux Hash](https://docs.remnux.org/install-distro/install-from-scratch#get-remnux-installer). Once the hashes match up, let's keep moving: ```bash mv remnux-cli remnux chmod +x remnux sudo mv remnux /usr/local/bin ``` Now we've got the CLI sorted, we need to get some dependencies in before we can kick off the REMnux installer: ```bash sudo apt install -y gnupg curl ``` If you've been following along, this should already be there - but if not, this command's got you covered. Right, now for the main event - let's get REMnux installed: ```bash sudo remnux install --mode=cloud ``` We're using that cloud flag because we're setting this up in Azure, and we want to keep the SSH daemon running so we can actually get back in! It's not a bad idea to add some extra security though - we'll get to that in a bit. This installation's going to take its sweet time, probably 1-2 hours, so maybe grab a coffee/tea or three. When it's done, give it a quick reboot: ```bash sudo reboot ``` ### System Hardening This bit's optional, but honestly? It's worth doing as it helps to harden your systems and apply layered security. Defence in layers... just like an Onion... or cake, _everyone_ loves cake. Once everything's installed and your system's back up, let's make it a bit more secure. Yeah, we've got our NSG and JIT rules, but why stop there? More security is always better, right? Jump into your SSH daemon config file at `/etc/ssh/sshd_config`. Here's what we want to tweak: ```bash # Disable root login PermitRootLogin no # Use SSH Protocol 2 (more secure than Protocol 1) Protocol 2 # Disable password authentication (use key-based only) - steps for this one seen below # READ THE STEPS BELOW BEFORE IMPLEMENTING THESE CONFIGURATION ITEMS. PasswordAuthentication no PubkeyAuthentication yes # Disable empty passwords PermitEmptyPasswords no # Strict mode StrictModes yes # Disable X11 forwarding if you don't want VNC if you do want to use VNC don't configure this item. X11Forwarding no ``` Didn't set up SSH auth when you built your REMnux machine? No worries - we can sort that out with key-based authentication: ```bash # On your local machine - this creates a fancy new key with some extra security ssh-keygen -t ed25519 -a 100 # Using ED25519 because it's got better security ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server # Before you go turning off password auth, make sure this works! ``` Let's lock down those SSH file permissions (better safe than sorry): ```bash # On the server chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys ``` Quick note - while our template's using a public IP right now, that won't be the case in our actual malware lab. So things like UFW or fail2ban? Not really worth the hassle, and they might actually get in the way when we're poking at malware. If you're curious about who's been knocking at your SSH door? You can check the logs (if you've got your NSG or JIT set up right, you should only see yourself in here): ```bash sudo journalctl -u ssh ``` ### Configurations #### VNC Right, here's where it gets interesting - we're setting up VNC because we're going down the Apache Guacamole route, if you were doing Azure Bastion you don't need to do this step. We need both SSH and VNC access to our REMnux machine. First up, let's get TigerVNC and XFCE installed: ```bash sudo apt-get update sudo apt-get install tigervnc-standalone-server xfce4 xfce4-goodies ``` Time to set up your VNC password (make it a good one!): ```bash vncpasswd ``` Now we need a startup script so VNC kicks in when your _MalNux_ machine boots up. First, let's make a home for it, start by creating a `.vnc` folder. ```bash mkdir -p ~/.vnc ``` Here's the script - just copy the whole thing: ```bash cat > ~/.vnc/xstartup << 'EOF' #!/bin/bash unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS export XDG_SESSION_TYPE=x11 export XDG_CURRENT_DESKTOP=XFCE export XDG_CONFIG_DIRS=/etc/xdg export XDG_DATA_DIRS=/usr/share /usr/bin/startxfce4 EOF ``` Make that script runnable: ```bash chmod +x ~/.vnc/xstartup ``` Last bit - we need to set up TigerVNC as a system service. Copy this whole chunk (but remember to swap out `groot` or `remnux` for whatever username you're using): ```bash sudo tee /etc/systemd/system/tigervncserver@:1.service << 'EOF' [Unit] Description=Start TigerVNC server at startup After=syslog.target network.target [Service] Type=forking User=groot Group=groot WorkingDirectory=/home/groot Environment=HOME=/home/groot Environment=USER=groot Environment=DISPLAY=:1 ExecStartPre=/bin/bash -c '/usr/bin/vncserver -kill :1 || true' ExecStartPre=/bin/bash -c 'rm -rf /tmp/.X11-unix/X1 || true' ExecStartPre=/bin/bash -c 'rm -rf /tmp/.X1-lock || true' ExecStart=/usr/bin/vncserver :1 -localhost no ExecStop=/usr/bin/vncserver -kill :1 [Install] WantedBy=multi-user.target EOF ``` Now that we've got our service file, let's make sure the permissions are right: ```bash chmod 755 ~/.vnc/xstartup ``` Time to fire it up: ```bash # Reload systemd to recognize the new service sudo systemctl daemon-reload # Enable the service to start on boot sudo systemctl enable tigervncserver@:1.service # Start the service sudo systemctl start tigervncserver@:1.service ``` Let's make sure it's actually running: ```bash systemctl status tigervncserver@:1.service ``` Below is a collection of basic commands for managing TigerVNC on your REMnux machine. ##### Handy VNC Commands Here's your cheat sheet for managing TigerVNC: Want to start it? `sudo systemctl start tigervncserver@:1.service` Need to stop it? `sudo systemctl stop tigervncserver@:1.service` Something weird? Try: `sudo systemctl restart tigervncserver@:1.service` Check if it's happy: `sudo systemctl status tigervncserver@:1.service` ##### When Things Go Wrong Check the service logs: `journalctl -u tigervncserver@:1.service` See what VNC's up to: `tail -f ~/.vnc/*.log` See what servers are running: `vncserver -list` ##### Good to Know VNC usually hangs out on port 5901, but you might want to change that for extra security. Whatever port you pick, make sure it's open on your NSG for the _Mal_Net_ network (check out [[Azure Malware Lab Network Build]] for the details). A few other tips: - We've set it up with `-localhost no` so you can connect from outside - Make sure your firewall's happy with VNC connections - Please, *please* use a strong password - SSH tunnelling's not a bad idea for extra security ##### Common Headaches and How to Fix Them 1. Service won't start? Check these: - Is there a VNC password? `ls -la ~/.vnc/passwd` - Did we set the permissions right? `ls -la ~/.vnc/xstartup` - What do the logs say? `journalctl -u tigervncserver@:1.service -n 50` 2. Can't see your desktop? - Make sure XFCE's actually there: `dpkg -l | grep xfce4` - Double-check those xstartup permissions - Take a peek at the VNC logs in `~/.vnc/` And there we have it - we're all set! Both our templates are ready to rock and roll. Next up, we'll take these templates we've built and move onto [[Azure Malware Lab Preparation]], where things really start getting interesting.