When working remotely (i.e. away from home) I often think about how it would be great if I could open up some of my internal projects when I have spare time and carry on working on them. There are multiple options on how I could do this, some are costly (moving environment to cloud) and some require looking at security (using remote software, opening firewall ports etc).
In this blog post I’m going to look at using a SOCKS proxy and a Linux instance (virtual box in the post, could possible be a Raspberry Pi) as a bastion host type device.
What’s A SOCKS Proxy?
A SOCKS proxy works at layer 5 (Session Layer) of the OSI model. A SOCKS proxy proxies connections so that the traffic going via the SOCKS proxy gives the details of the SOCKS proxy and not the original device. For example, if I connect my laptop (IP A) to the SOCKS proxy (IP B) and then open a web site, the website sees the details of IP B.
Please note I’ve simplified this explanation, i.e. if the laptop and SOCKS proxy are behind the same NAT router then they probably have the same public IP address anyway.
Why Not Use VPN?
A VPN server is an option here (rather than SOCKS) but generally has a lot more work involved in setting up / maintaining, especially for a test project such as this one.
What’s A Bastion Host?
A Bastion is a type of structure that is part of a fortifications wall. The Bastion sticks out, allowing for soldiers to defend the fortifications walls with ranged attacks.
In modern technology a Bastion Host is a device that sits either in the demilitarised zone (DMZ) of a network, just outside of the firewall or is set as an reachable destination behind Network Address Translation (NAT) routers. The Bastion Host is stripped of most applications / services, has its security pumped up and then is generally used for one purpose (e.g. a proxy server, a VPN server) that requires it to be internet accessible.
Bastion Hosts generally have network capacity to handle large volumes of traffic incase of a network attack (e.g. a Denial Of Service (DOS) or Distributed Denial Of Service (DDOS) attack).
Outside of experimenting I would recommend using a Linux instance with SSH configured on a different port (not the default of 22), SSH configured not to use passwords (relying on SSH private/public keys instead), auth logs logging as much as possible. I would also recommende havUFW is enabled to block all ports I’m not using, and to only allow traffic from / to IP addresses I’m using. That last bit may be a pain if using static IP addresses (e.g. IP addresses that change regularly).
Sending Traffic via the SOCKS Proxy
To show the potential use I’ve set up a virtual Linux instance running a website (in this case Media Wiki) on port 80 (HTTP). The virtual instance is running on IP address 192.168.56.2. I have then enabled a firewall to allow traffic from my machine (192.168.56.1) to 192.168.56.2 but only for ports 22 (SSH) and 8888 (the port I’m going to proxy over):
If I try to visit the website with the rules enabled and no proxy I get a connection time out:
However, if I open a terminal and type the following:
ssh -i <KEY HERE> USER@HOST -D 8888 -N
I can open a SSH connection, forward traffic over port 8888 (using -D) and keep the connection open without sending a command (using -N). Then in my web browser (in this case, FireFox) I can adjust my network settings so that a SOCKS proxy is used over localhost port 8888.
As long as the SSH connection is open I can then browse to the website without the firewall rules effecting me.
One thought on “SOCKS Proxy (Linux)”
Comments are closed.