Posted by: Eric Hansen
Proxy, security, SSH, Tutorial
When I was working at Ford, you were put behind a proxy. The idea intrigued me, as it was able to handle so many connections at once. Since then, I’ve been thinking of different ways to develop proxies, and looked at current solutions. If you want the easy pleasy way of doing things, then Tor is your best option (though, granted, not always the most safest). However, if you want to trust a reliable connection, you can easily set one up to go through your home (or business) network. Keep in mind, this is going to focus more on secure measures, and is meant for businesses who want to set up a network proxy.
First things first, the access. Thinking about this first makes everything a whole lot easier down the line, and there’s a couple of ways to go about this. If you’re going to allow only a select few people to use the SSH proxy, you can use AllowUsers, but if you have a lot of people who will use it, its easier to just do AllowGroups. Both of these function the same, but using either one of these will turn your proxy into a restrictive proxy. AllowUsers is easy to maintain if you have a small group, but gets increasingly hard the more people you have in the list. AllowGroups is pretty easy to maintain, period. The assumption in this will be that you use AllowGroups, because why make your job harder than it has to be, right?
Now that you have that out of the way, setting up the daemon. On my set up, I already have a SSH server running so that I can manage the server whenever I please. Due to this, I wanted to keep my access server and proxy server separate. To do this, create a new (or just copy your sshd_config) file in /etc/sshd (or wherever sshd_config is for the sake of being easy to keep track of); I’ll show a sample of mine after I address something. When you edit this file, there’s two important lines to take note of.
The port number might be different (22 is standard), but you need to edit this to something that is not being used. Personally I use some random high port number, in case I decide to take a stab at running SSH from a non-root account. The next line, which may (or may not) already be there is, you guessed it, AllowGroups.
If its not there, then add it, and place the group which will be allowed access to the proxy. Save this as something you’ll remember (or copy your SSH init.d script and rename it something like proxyd or whatnot).
Before starting up the proxy, we have to create and/or add the user to the group. First, make sure the group exists (grep group_name /etc/group), and if not, create it (groupadd group_name). Next, make sure any accounts that are allowed proxy access are a part of it (usermod -aG group_name user_name). Then, when you create a new user, just append group_name to the already given list of groups.
Now that we got that all taken care of, make sure that your proxy init script has the correct information (config file mostly), and then do /etc/init.d/proxyd start or however you start up your services. If all goes well, you should see the new port you gave the proxy listed when you run netstat -ntl (or netstat -ntlup if you’re like me and like verbose output). If that goes well, then do a simple SSH connection test (ssh -p port_number username@ip_address), making sure to use a username that is a part of the proxy’s allowed groups. If all goes well, you’re almost there! If not, then fix the issue (I haven’t run into any issues doing this this way, so I can’t advise anything without actually knowing your issues).
From here, go to any workstation you have access to, and run the following command:
ssh -ND localhost:10001 -p proxy_port proxy_name@proxy_ip_or_host
What this does is is bind a SSH connection session (D) to localhost on port 10001 to the proxy server, authenticating as the proxy username, in a non-interactive shell (N). However, doing this will not make the process run in the background (it’ll act like a normal SSH session, without any prompts besides for the proxy account password). If you want it to run the background after authentication is successful, add a “f” in the “-ND” part, so it looks like “-fND”. This forces it into the background. Now, something to take note of. I’ve not had much luck using this as an actual HTTP(S) proxy, but if you set up your browser (like Firefox, or IE even) to use this as a SOCKS v5 proxy, it seems to work just fine.
This is a great way to monitor who has internal and external network access. Using a couple of simple firewall rules, you can make this your only outbound-able connection source on a subnet/VLAN/etc… Actually, I’ll cover some useful iptables rules soon, as its really gotten me interested in all the crazy things you can do with it. If you want a real world example of how this can be used, I have my web server set up to refuse access to specific websites it hosts unless the remote IP is coming from itself (which, when doing this, your Intranet servers will see the IP as being the same as the server itself). This, to me, is a lot better than doing .htaccess and the like for small things.