Last year I was out of the country and wanted to check some things on my home network. I connected to the guest-only wifi network provided in the hotel lobby and was thoroughly annoyed to find that I could not connect to my OpenVPN server. I did a bit of probing and found the hotel firewall was only allowing outgoing traffic on TCP/UDP 53 (DNS), TCP 80 (http) and TCP 443 (https). I thought this was a bit silly given how many businesses use VPNs nowadays and I wondered what kind of firewall they had in place. One way to find out!
I went over to a local friend's place and used his unrestricted wifi to access my home network to do the following:
- Create a VM for use as a jump/bastion server.
- Harden the ssh server.
- Forward TCP port 80 on my public IP address to TCP port 22 (ssh) of said jump server.
There are too many variables on hardware and software out there to give a full tutorial on creating VMs and port forwarding but I can give some general specifics (that's a thing right?) for a Linux based ssh server.
SSH Server Hardening Basics
Since the ssh server will be public-facing, only install the bare necessities - the more services and software you have, the bigger attack surface you are providing. Other than enabling a ssh server, the only other thing I installed was python as I was planning on using sshuttle.
It should go without saying but make sure you have updated the OS and any software installed.
Generating RSA Keys
Follow this tutorial for an overview on generating RSA keys in Ubuntu. For Windows, I recently started using MobaXterm as a ssh client and it comes with its own SSH key generator. I strongly suggest using a passphrase to secure your key.
Changes to /etc/ssh/sshd_config
This is by no means an exhaustive list of things you can do but it does cover the low-hanging fruit. Many of the configuration changes are controlled by /etc/ssh/sshd_config so I'll go over them here. As with any critical configuration file, it's a good idea to make a backup in case you screw something up.
- Enable Public Key Authentication
Look for a line "PubkeyAuthentication" and set it to yes. You probably just need to uncomment it.
- Disable root login
I connect with a user account with sudo access. Look for "PermitRootLogin" and set it to no.
- Restrict Users
Whitelist your login by adding a line "AllowUsers <your username>"
- Allow TCP forwarding
This needs to be enabled to get access to the rest of your network. Look for "AllowTcpForwarding" and set it to yes. You probably just need to uncomment it.
- Disable X11 forwarding
Look for "X11Forwarding" and set it to no. There's no need to forward a X11 display that doesn't exist.
- Change default ciphers and algorithms. Great info here.
I added the below to the bottom of my sshd_config:
Restart the ssh service and make sure you can connect with your key. Once you've confirmed that to be working, edit the sshd_config file, change "PasswordAuthentication" to no then restart your ssh service again.
Confirm that file permissions are locked down for /home/<your_user>/.ssh/authorized_keys.
Now that all that is done, do the port forwarding on your router/firewall.
Connecting to Your Network
After finishing all this up at my friend's house, I went back to the hotel to try things out. I booted up my Kali machine and tested with the command
sshuttle -r <my_user>@<my_public_ip>:80 <my_network>/<my_subnet_mask> --exclude <internal_ip_of_jump_server> --dns
After connecting with
sshuttle I had full access to my home network and could connect to things by internal DNS name.
Additional Config After Returning Home
That was a quick and dirty workaround that did the job while I was traveling but with it being a public facing server, more was needed:
apticron- notifies you of package updates
- AIDE - Advanced Intrusion Detection Environment, configured to send daily emails about any changes to critical/system files
- Enable Multi-Factor Authentication