Website Admin Panel on Private Network

Running your website’s administration panel on a private network can help increase security along with increase your website’s performance if you perform demanding administrative tasks. This post will cover the idea of running a website admin panel on a private network instead of making it public while still having full control over the public site’s data. I haven’t yet done this in a production environment, but the site I’m currently working on will most likely implement a method similar to the one below.

Network Setup

This tutorial assumes you have two networks, a remote hosting network (vps, shared hosting, cloud server), and a private network (i.e. your office). Our goal is to add a web server to your private network that can manage your site. For this tutorial, I will refer to your website’s network as the Website Network and the network the administration panel will be located on as the Admin Network.

The first step requires you to add a SSH server to your website’s database server (or a server on the same subnetwork as the database server). This requirement allows us to use a SSH tunnel to connect to the database remotely through SSH without enabling remote connections on the database. This step can be repeated for additional services on your Website Network that the Admin Network needs access to.

As for the Admin Network, a web server has to be configured to serve the administration panel. This will include a web server application (nginx, apache), the language interpretor (php, perl, python, node), and any additional libraries or programs required. Keep in mind that the Admin Network shouldn’t be used to send e-mails or perform remote actions. Instead, the Admin Network should make a request to your Website Network for actions that need to be performed.

Connecting to the Database

To have your administration panel use the same database as your website, you want to create a SSH tunnel to the database server. Keep in mind that if you have multiple master and slave servers, additional configuration would be required to utilize their existence. Creating a SSH tunnel requires the database server to have an OpenSSH server installed.

On the Admin Network, you need to create a SSH connection that tunnels traffic from a local port to the Website Network that will then foward the request to the database. Later on you will use the Admin Network server that created the SSH tunnel as the connection to the database server. Read the post “Connect to Remote MySQL Server” on VPS Info that talks about setting up this connection in depth.

$ ssh user@website-network -L 3306:localhost:3306 -N

Configure Administration Panel

Configuration of your administration panel shouldn’t vary from the normal configuration. You will have to modify the database information to use the Admin Network server that is running a SSH tunnel to the remote database.

If your administration panel can send e-mails to users, it has to be modified to use your Website Network as the SMTP server instead of localhost. This can be done either through another SSH tunnel or using remote SMTP to your website’s mail server. A third option is to add message that’s supposed to be sent to the database and have a remote cron job send all pending messages.

Accessing your Administration Panel

To access the administration panel you would navigate your web browser to the Admin Network IP address or host instead of to the Website Network. There are a few things you can do to make accessing the administration panel easier. One method is to add a new DNS record for a sub-domain that points to the private IP address of the admin server. The public will be able to see this IP address but won’t be able to access it since it’s in your subnetwork. An alternative method would be edit your subnetworks DNS records instead.

admin	IN A 192.168.0.100

If you need people from outside of the subnetwork to access the administration panel, this is still possible. You can configure a VPN (most routers have one built in), and people can VPN to your private network to then access the administration panel through the same private IP address or host name.

Final Thoughts

Running the administration panel locally can add additional work (as you can see above), but I believe it’s a worthy investment. There is almost no reason to have the administration panel publicly available. As for remote users, they can always access the administration panel network by using a VPN.

As for how the code should be structured during development, I would suggest having a single repository that contains both the site and administration panel since they have to use many of the same models and libraries. Also changes to the website probably directly affects changes to the administration panel. I would separate files that are unique to the administration panel into a different directory and namespace and create an entry point that is for the administration panel and one for the website.

project
|-- config
|-- share
|-- src
|   |-- admin
|   |   |-- inc
|   |   |-- public
|   |   |   |-- admin-router.php
|   |   |
|   |   |-- themes
|   |
|   |-- app
|   |   |-- inc
|   |   |-- public
|   |   |   |-- app-router.php
|   |   |
|   |   |-- themes
|   |
|   |-- inc
|   |-- libraries
|
|-- tests

There are a few things you need to keep in mind when splitting up the administration panel from the website. Look over the list below before moving forward.

• It’s still important to require authentication on the administration panel.
• Secure all servers the same way you would with a publicly accessible server.
• Don’t upload the administration panel onto your website’s server.
• Ensure the administration panel and the website are on the same version.

With those final thoughts, I’m done. Hopefully this gets you thinking about different ways to setup your administration panel. There is probably much more that can be said on this topic, but I wanted to get the basic idea out there.