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.
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
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.
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.
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.