Secret server
Dennis Jarecke takes an existing website on his home server and hides it from everyone but his closest friends. You never know who’s looking…
Dennis Jarecke takes an existing website sitting on your home server and hides it from everyone but your closest friends using the OpenVPN library.
Let’s face it. There’s always a shady organisation or overreaching government wanting to hack your system and spy on your life. Keeping your internet activity secure can be difficult, especially if you’ve got servers you want hidden from everyone except a few trusted individuals. That’s the point of what we’re going to do in this article. We’re going to show you how to access your own web server from anywhere in the world without anyone knowing about it.
There are several ways you can create secure connections between two computers, but for our purposes we’re going to use OpenVPN. It’s considered one of the best solutions available because it’s based on sound encryption algorithms, it’s open source and it’s highly configurable. It creates an encrypted tunnel between two computers using OpenSSL which makes it possible for data to be transferred, without that data being compromised.
Here’s the scenario. Imagine you’re running OpenSUSE Leap 42.3 with a website you want to access without anyone knowing it exists. The site is up and running and working great behind your router.
But now you want to access the server from anywhere in the world. You could go to your router and route HTTP traffic to your Linux machine, but that would expose your computer to every hacker on the planet. Alternatively, you can create an OpenVPN tunnel between your laptop and desktop computer that only you have access to. This will keep your activity hidden because you’re not connecting to ports 80 or 443, and your traffic will be encrypted for maximum security. Let’s see how you can implement this for yourself.
Setting up OpenVPN has lots of steps, and the first time you do it it’s difficult. There are technical concepts you need to understand and usually up to 10 files you need to create. Plus, there are lots of configurations that are talked about online, and each one has its own set of steps that may not be applicable to our situation here. If this is new to you, focus on routing tables and OpenSSL’s public key infrastructure to understand what’s going on. Here’s a summary of what happens. In the configuration files you’ll designate a network for OpenVPN (like 10.0.0.0/24), and the OpenVPN software will create a virtual network adaptor for it (like tun0). OpenVPN will modify the Linux routing table to send 10.0.0.0/24 packets through tun0. Virtual and physical adaptors Outgoing packets are encrypted with OpenSSL at the virtual network adaptor (tun0), forwarded via the routing table to the physical adaptor (eth1), and sent out to the internet. Incoming packets arrive at the physical adaptor (eth1) on port 1194, are forwarded to the virtual adaptor (tun0), decrypted with OpenSSL, and then sent to local programs like Apache. As an enduser, all you have to do is interact with the IP address of the virtual network adaptor created automatically when
OpenVPN is started. In other words, you treat 10.0.0.0/24 as any other external network, but with the confidence that your packets are secure.
The OpenVPN documentation says you may need to tell Linux to forward traffic between ethernet devices. The command sysctl -w net.ipv4.ip_forward=1 will get forwarding working between your physical and virtual adaptors.
It’s important to note that the firewall will sit between your virtual network adaptor and local programs like Apache and between the virtual adaptor and the physical adaptor. The diagram ( left) shows the INPUT, Output, and Forward chains in the filter table, but the PREROUTING and POSTROUTING chains can also impact your configuration if you’re not careful.
The OpenVPN authentication, encryption, and decryption occurring at tun0 is handled by OpenSSL.
OpenSSL is a general-purpose cryptography library for creating and managing a public key infrastructure (PKI). While this may be familiar, let’s review because it’s a major component of OpenVPN and a big step in the configuration process.
When two people want to communicate privately they create private and public keys, and then exchange their public keys while keeping their private keys secret. Messages are encrypted with public keys and can only be decrypted with the matching private key. Messages can be signed with a private key and verified with a public key. This means messages can be encrypted and authenticated in one easy framework. Public keys are often referred to as a certificate, or cert for short.
The situation is usually complicated by adding a Certificate Authority, or CA for short. The CA is a person or business with their own private key and corresponding certificate. The purpose of the CA is to sign other people’s certificates. In other words, the CA adds another layer of validation and verification. For OpenVPN, it means you can revoke access to your OpenVPN server at any time It’s useful to remember what happens with HTTPS traffic. When calling a secure website via https://, the server sends its certificate signed by a CA to your browser. The browser will verify the signed certificate using the public certificate of the CA. Then, the browser will generate a key, encrypt it with the server’s public certificate, and send it to the server. Going forward, communication between browser and website will be encrypted symmetrically with that key.
In OpenVPN, both the server and client machines will have a CA cert as well as public and private keys. (You’ll see how those are created below.) When a client machine connects to an OpenVPN server, both machines will exchange their public certificates and verify them with the CA certificate. Then, both computers will randomly generate keys, encrypt them with each other’s certificates, and exchange them with each other. Data is then encrypted with these keys. These keys are never used bidirectionally because they are in HTTPS traffic.
Now with all this explanation behind us, let’s get you up and running with a real OpenVPN configuration. You’ll need two computers to do this. One will act as a server and the other will act as a client. In this example, the OpenVPN server is an OpenSUSE 42.3 desktop and the client is a laptop also running OpenSUSE 42.3. Apache should be running and serving up the web site you want to keep hidden. Both computers will need OpenVPN installed (there’s no difference between server and client OpenVPN software) so either download it or install it through your distribution’s package manager. On OpenSUSE run zypper install and openvpn.
Diffie Hellman
Creating the private keys and certificates turns out to be easy. The OpenSSL commands can be complicated so there’s a program called easy-rsa that makes building the keys and certs quick and simple. Run zypper and install easy-rsa to install it.
Once installed, navigate to /etc/easy-rsa and modify the vars file if you want to change any defaults. If this is your first time, leave it alone until you’re more comfortable with OpenVPN. Next, run the command easyrsa init-pki . This will create the directory /etc/ easy-rsa/pki where your keys and certs will be created. Now run the command easyrsa build-ca to create a CA key and cert. Make sure you enter a password and record it in your password manager. Once the command is finished you’ll find that you’ve created /etc/easy-rsa/pki/ca.crt and /etc/easy-rsa/pki/ private/ca.key. Next, run the command easyrsa build-server-full
server nopass . It will ask for the password to your CA key. This will create issued/server.crt and private/
server.key in the /etc/easy-rsa/pki directory. These are your server key and certificate, respectively. Doing this will automatically sign your server.crt with the
ca.key file above. To create the client key and certificate, run the command easyrsa build-client-full client nopass . This will create issued/client.crt and private/client.key in the /etc/easy-rsa/pki directory. The client.crt file will be automatically signed by the ca.key file.
Now let’s build the Diffie Hellman parameters with the command easyrsa gen-dh . This will create /etc/
easy-rsa/pki/dh.pem. This is important because the RSA certificates are used for authentication, but not for encrypting data across the tunnel. It’s too slow. With Diffie Hellman parameters keys can be quickly created