One of the disadvantages that SmartVPSs or SmartServers have compared to traditional dedicated servers is that you can't stick an ASA5505 (or some other hardware firewall) in front of it for VPN connectivity.
Many times, customers are looking to have some sort of internal site that they don't want being visible to the outside world. So how can we accomplish something like this without a VPN? Read below the fold to find out.
As many of the things I discuss on this site are considered best effort, it should be surprised to find me posting this caveat: What you are about to read discusses things that would fall under our best effort support. While we would be more than happy to assist where possible, we can't necessarily guarantee results.
However, with that out of the way, I will say that in my testing, this procedure seems to work pretty well. So let's get on with the show!
Kick your SmartServers
The idea here is that you will have public facing server, and one "closed" server. This article will be using the "example.com" domain. Who would have thought?
In this case, you would create the two servers with hostnames something similar to "open.example.com" and "closed.example.com". In regards to the image, it doesn't really matter, but most people will probably want cPanel, as it make adjusting of IPs for sites much easier, so that's what I will use in the example here.
Once the servers are created, make sure that they have private networking enabled. For this tutorial, let's assume that "open.example.com" has a private IP of 10.38.4.132, and "closed" has 10.38.4.133
Lockdown the "closed" server
So the first course of business is to lock down the "closed" server by utilizing the SmartServer Advanced Firewall. This way, great granularity can be achieved in what is open and what isn't. The basic idea is that you will only want to allow traffic on the private network or to Liquid Web so that we can monitor your servers. Additionally, you may want to leave WHM accessible to the outside so you won't have to jump through hoops to access it. Below is the configuration that I have tested and used:
LABEL SOURCE IP DESTINATION IP DESTINATION PORT PROTOCOL ACTION
Internal 10.38.4.0/24 10.38.4.133 * any allow
WHM External * 184.108.40.206 2087 any allow
Allow internal 10.0.0.0/8 220.127.116.11 * any allow
Block outside * 18.104.22.168 * any deny
At this point, the only thing that you should be able to access from the outside world is WHM, as it utilizes port 2087 for secured connections. If you want, you may want to allow access to 2083 as well. That way you can access the specific cPanel accounts from the outside as well (of course, in a secured manner) without having to tunnel in.
Create the internal site
Now that "closed.example.com" is secured, you can go ahead and create the cPanel account for the internal site. In this case, I called it "internal.example.com". After creating it, I changed the IP for the site from the default shared IP to the internal, private networked IP.
You'll also want to do the needful in regards to DNS so that "internal.example.com" points to 10.38.4.133
Keep in mind, to upload content, you will need to tell your SFTP client (SFTP good, regular FTP bad) to use a proxy. This will be discussed in the next section.
So now that things are all locked down, how do you access it?
Depending on what operating system you are using, the exact process will vary, but the principal is similar. Essentially, you would create a user that you would like to use for the purpose of the tunnel on "open.example.com, and when you SSH into the open server, tell your SSH client to setup a SOCKS tunnel.
A quick google search will tell you how to establish the tunnel based on your OS. So for example, you could search with a string such as "SSH proxy windows" or "SSH proxy linux".
Once the tunnel is established, all you need to do will have your browser (or (S)FTP client) utilize the proxy, which in 99% of the cases, will be "localhost" and whatever port number you decided to choose upon creation of the tunnel.
Pro Tip: For additional security, you could disable interactive (keyboard) authentication, and require keys be used into "open.example.com"
That's the down and dirty of this method of securing an internal site. For me, it worked. Again, it's technically best effort support, although many of the processes I described are things that we can probably assist you with.
Feel free to leave a comment here if you need assistance, or ping your friendly Liquid Web support technician who can certainly get a hold of me if they have any questions.Tweet