Cre­ate se­cret and se­cure web servers; pre­dict the weather us­ing your Pi; surf se­curely with a VPN; cre­ate a mo­saic por­trait.

1 THE BA­SICS Here’s the sce­nario: Imag­ine you’re run­ning OpenSUSE Leap 42.3 with a web­site you want to ac­cess without any­one know­ing it ex­ists. The site is up and run­ning, and work­ing great be­hind your router.

But now you want to ac­cess the server from any­where in the world. You could go to your router and route HTTP traf­fic to your Linux ma­chine, but that would ex­pose your com­puter to ev­ery hacker on the planet. Al­ter­na­tively, you can cre­ate an OpenVPN tun­nel be­tween your lap­top and desk­top com­puter that only you have ac­cess to. This keeps your ac­tiv­ity hid­den, be­cause you’re not con­nect­ing to ports 80 or 443, and your traf­fic is en­crypted for max­i­mum se­cu­rity. Let’s see how you can im­ple­ment this for your­self.

Set­ting up OpenVPN has lots of steps, and the first time you do it, it’s dif­fi­cult. There are tech­ni­cal con­cepts you need to un­der­stand, and usu­ally up to 10 files you need to cre­ate. Plus, there are lots of con­fig­u­ra­tions that are talked about on­line, and each one has its own set of steps that may not be ap­pli­ca­ble to our sit­u­a­tion here. If this is new to you, fo­cus on rout­ing ta­bles and OpenSSL’s pub­lic key in­fra­struc­ture to un­der­stand what’s go­ing on.

Here’s a sum­mary of what hap­pens: In the con­fig­u­ra­tion files, you des­ig­nate a net­work for OpenVPN (such as, and the OpenVPN soft­ware cre­ates a vir­tual net­work adapter for it (such as tun0). OpenVPN mod­i­fies the Linux rout­ing ta­ble to send packets through tun0 [ Im­age A].

2 VIR­TUAL AND PHYS­I­CAL ADAPTERS Outgoing packets are en­crypted with OpenSSL at the vir­tual net­work adapter (tun0), for­warded via the rout­ing ta­ble to the phys­i­cal adapter (eth1), and sent out to the In­ter­net. In­com­ing packets ar­rive at the phys­i­cal adapter (eth1) on port 1194, are for­warded to the vir­tual adapter (tun0), de­crypted with OpenSSL, then sent to lo­cal pro­grams, such as Apache. All you have to do is in­ter­act with the IP ad­dress of the vir­tual net­work adapter cre­ated when OpenVPN starts. In other words, you treat as any other ex­ter­nal net­work, but with the con­fi­dence that your packets are se­cure.

The OpenVPN doc­u­men­ta­tion says you may need to tell Linux to for­ward traf­fic be­tween Eth­er­net de­vices:

sysctl -w net.ipv4.ip_ for­ward=1 gets for­ward­ing work­ing be­tween your phys­i­cal and vir­tual adapters.

It’s im­por­tant to note that the fire­wall sits be­tween your vir­tual net­work adapter and lo­cal pro­grams, such

as Apache, and be­tween the vir­tual adapter and the phys­i­cal adapter [ Im­age B]. The di­a­gram shows the In­put, Out­put, and For­ward chains in the fil­ter ta­ble, but Prerout­ing and Postrout­ing chains can also im­pact your con­fig­u­ra­tion if you’re not care­ful.

The OpenVPN authentication, en­cryp­tion, and de­cryp­tion oc­cur­ring at tun0 [ Im­age C] is han­dled by OpenSSL. OpenSSL is a gen­eral-pur­pose cryp­tog­ra­phy li­brary for cre­at­ing and manag­ing a pub­lic key in­fra­struc­ture (PKI). While this may be fa­mil­iar, let’s re­view it, be­cause it’s a ma­jor com­po­nent of OpenVPN, and a big step in the con­fig­u­ra­tion process.

When two peo­ple want to com­mu­ni­cate pri­vately, they cre­ate pri­vate and pub­lic keys, then ex­change their pub­lic keys while keep­ing their pri­vate keys se­cret. Mes­sages are en­crypted with pub­lic keys, and can only be de­crypted with the match­ing pri­vate key. Mes­sages can be signed with a pri­vate key and ver­i­fied with a pub­lic key. This means mes­sages can be en­crypted and au­then­ti­cated in one easy frame­work. Pub­lic keys are of­ten re­ferred to as a cer­tifi­cate, or cert for short.

The sit­u­a­tion is usu­ally com­pli­cated by adding a cer­tifi­cate au­thor­ity, or CA for short. The CA is a per­son or busi­ness with their own pri­vate key and cor­re­spond­ing cer­tifi­cate. The pur­pose of the CA is to sign other peo­ple’s cer­tifi­cates. In other words, the CA adds an­other layer of val­i­da­tion and ver­i­fi­ca­tion. For OpenVPN, it means you can re­voke ac­cess to your OpenVPN server at any time.

It’s use­ful to re­mem­ber what hap­pens with HTTPS traf­fic. When call­ing a se­cure web­site via https://, the server sends its cer­tifi­cate signed by a CA to your browser. The browser ver­i­fies the signed cer­tifi­cate us­ing the pub­lic cer­tifi­cate of the CA. Then the browser gen­er­ates a key, en­crypts it with the server’s pub­lic cer­tifi­cate, and sends it to the server. Go­ing for­ward, com­mu­ni­ca­tion be­tween browser and web­site is en­crypted sym­met­ri­cally with that key.

In OpenVPN, both the server and client ma­chines have a CA cert, as well as pub­lic and pri­vate keys. (You’ll see how those are cre­ated below.) When a client ma­chine con­nects to an OpenVPN server, both ma­chines ex­change their pub­lic cer­tifi­cates and ver­ify them with the CA cer­tifi­cate. Then both com­put­ers ran­domly gen­er­ate keys, en­crypt them with each other’s cer­tifi­cates, and ex­change them with each other. Data is then en­crypted with these keys. These keys are never used bidi­rec­tion­ally, be­cause they are in HTTPS traf­fic.

3 OPEN­ING MOVES WITH OPENVPN Now, with all this ex­pla­na­tion be­hind us, let’s get you up and run­ning with a real OpenVPN con­fig­u­ra­tion. You need two com­put­ers to do this. One acts as a server and the other acts as a client. In this ex­am­ple, the OpenVPN server is an OpenSUSE 42.3 desk­top, and the client is a lap­top also run­ning OpenSUSE 42.3. Apache should be run­ning and serv­ing up the web­site you want to keep hid­den. Both com­put­ers need OpenVPN in­stalled (there’s no dif­fer­ence be­tween server and client OpenVPN soft­ware), so ei­ther down­load it or in­stall it through your distri­bu­tion’s pack­age man­ager. On OpenSUSE, run the com­mand zyp­per in­stall openvpn .

4 DIFFIE-HELLMAN Cre­at­ing the pri­vate keys and cer­tifi­cates turns out to be easy. The OpenSSL com­mands can be com­pli­cated, so there’s a pro­gram called easy-rsa that makes build­ing the keys and certs quick and sim­ple. Run the com­mand zyp­per in­stall easy-rsa to in­stall it.

>> Once in­stalled, nav­i­gate to “/etc/easy-rsa” and mod­ify the “vars” file if you want to change any de­faults. If this is your first time, leave it alone un­til you’re more com­fort­able with OpenVPN. Next, run the com­mand

easyrsa init-pki . This cre­ates the di­rec­tory “/etc/easyrsa/pki,” where your keys and certs will be cre­ated.

>> Now run the com­mand easyrsa build-ca to cre­ate a CA key and cert. Make sure you en­ter a pass­word and record it in your pass­word man­ager. Once the com­mand is fin­ished, you’ll find you’ve cre­ated “/etc/easy-rsa/pki/ ca.crt” and “/etc/easy-rsa/pki/pri­vate/ca.key.” >> Next, run the com­mand easyrsa build-server-full

server nopass . It asks for the pass­word to your CA key. This cre­ates “is­sued/server.crt” and “pri­vate/server. key” in the “/etc/easy-rsa/pki” di­rec­tory. These are your server key and cer­tifi­cate, re­spec­tively. Do­ing this au­to­mat­i­cally signs your “server.crt” with the “ca.key” file above.

>> To cre­ate the client key and cer­tifi­cate, run the com­mand easyrsa build-client-full client nopass . This

cre­ates “is­sued/client.crt” and “pri­vate/client.key” in the “/etc/ easy-rsa/pki” di­rec­tory. The “client.crt” file is au­to­mat­i­cally signed by the “ca.key” file.

Now let’s build the Diffie-Hellman pa­ram­e­ters with the com­mand easyrsa gen-dh . This cre­ates “/etc/easy-rsa/pki/ dh.pem.” This is im­por­tant, be­cause the RSA cer­tifi­cates are used for authentication, but not for en­crypt­ing data across the tun­nel. It’s too slow. With Diffie-Hellman pa­ram­e­ters, keys can be quickly cre­ated to en­crypt data. This is faster and al­lows for re-key­ing per­sis­tent con­nec­tions.

Fi­nally, there’s an op­tional com­mand that adds an ad­di­tional sig­na­ture to all SSL/ TLS hand­shake packets for in­tegrity ver­i­fi­ca­tion. Run “openvpn > genkey > se­cret ta.key,” and place “ta.key” in “/etc/easy-rsa/pki.”

No­tice all the keys and cer­tifi­cates have been cre­ated on the same ma­chine. It doesn’t have to be this way. Ideally, the ma­chine with “ca.key” is des­ig­nated as a key sign­ing ma­chine, and should be sep­a­rate from the OpenVPN server. For max­i­mum se­cu­rity, the key sign­ing ma­chine should be off the net­work. In ad­di­tion, we could have cre­ated “client.key” on the client ma­chine, and sub­mit­ted a Cer­tifi­cate Sign­ing Re­quest to the key sign­ing ma­chine. Af­ter sign­ing, the “client.crt” file would be sent to the client ma­chine. This would be more se­cure, be­cause “client.key” would never have to leave the client ma­chine.

5 SE­CURE YOUR SERVER Copy “ca.crt,” “server.key,” “server.crt,” and “ta.key” to “/etc/openvpn.” Now, let’s look at a typ­i­cal con­fig­u­ra­tion. Call the file below “server.conf “and put it in “/etc/openvpn.” server proto udp port 1194 dev tun topol­ogy sub­net per­sist-key per­sist-tun keepalive 10 60 re­mote-cert-tls client tls-auth /etc/openvpn/ta.key 0 dh /etc/openvpn/dh.pem ca /etc/openvpn/ca.crt cert /etc/openvpn/server.crt key /etc/openvpn/server.key cipher AES-256-CBC user no­body group no­body verb 3 dae­mon log-ap­pend /var/ log/openvpn.log comp-lzo yes

This file opens UDP port 1194 for the phys­i­cal VPN con­nec­tion, and cre­ates a vir­tual “tun” Eth­er­net de­vice with sub­net No­tice that it ref­er­ences the four files we cre­ated. Af­ter start­ing, OpenVPN changes the user and group ID to no­body, for ad­di­tional pro­tec­tion of the server in case some­one man­ages to get con­trol of an OpenVPN ses­sion. A log file is de­fined, and the rec­om­mended ver­bosity level of 3 is se­lected. Fi­nally, we LZO com­press the data across the tun­nel.

Now let’s start the OpenVPN server. If you have a fire­wall run­ning, open port 1194 with some­thing like

ipt­a­bles -A IN­PUT -p udp -m udp --dport 1194 -j AC­CEPT . You can man­u­ally start OpenVPN with the

com­mand openvpn --con­fig /etc/openvpn/server.conf . To start it au­to­mat­i­cally at a re­boot, place the com­mand in “/etc/rc.d/af­ter.lo­cal.”

You can ver­ify OpenVPN is run­ning in sev­eral ways: 1. Use the top com­mand to find OpenVPN run­ning un­der user “no­body.”

2. Use if­con­fig or ip addr show to see that tun0 is at­tached to IP ad­dress

3. Use the route or ip route com­mand to see that is routed to tun0.

6 CLIENT CON­FIG Con­fig­ur­ing your client lap­top is al­most iden­ti­cal and quick to do. Use the fol­low­ing con­fig­u­ra­tion file: client re­mote openvpn-server-host­name-or-ip 1194 proto udp nobind dev tun per­sist-key per­sist-tun re­mote-cert-tls server tls-auth /etc/openvpn/ta.key 1 ca /etc/openvpn/ca.crt cert /etc/openvpn/client.crt key /etc/openvpn/client.key cipher AES-256-CBC user no­body group no­body verb 3 log-ap­pend /var/ log/openvpn.log comp-lzo yes

Here we’re declar­ing the lap­top as a client ma­chine, with the re­mote op­tion point­ing to the OpenVPN server. Make sure you re­place openvpn-server-host­name-or-ip with the IP ad­dress of your server. Call this “client.conf” and put it in “/etc/openvpn.” Next, trans­fer “ca.crt,” “ta. key,” “client.crt,” and “client.key” to the lap­top, and put them in “/etc/openvpn.” Fi­nally, start OpenVPN with

openvpn --con­fig /etc/openvpn/client.conf . You can ver­ify OpenVPN is run­ning with the same three meth­ods men­tioned above. But to make sure both ma­chines are con­nected, run ping , which pings the OpenVPN server from the client. If this works, the two ma­chines are con­nected via OpenVPN.

7 APACHE AC­TION Re­mem­ber that the goal is to con­nect to Apache run­ning on a Linux server through

OpenVPN. There are four more prob­lems that need to be over­come, and it turns out they’re easy to solve.

First, make sure the fire­wall has a port open with the com­mand ipt­a­bles -A IN­PUT -s -p tcp -m tcp --dport 80

-j AC­CEPT . Re­mem­ber, you spec­i­fied as the OpenVPN net­work in the “server.conf” file above. This makes sure Apache re­ceives the packets from the OpenVPN net­work.

The sec­ond prob­lem is con­fig­ur­ing Apache to re­spond to re­quests coming over the OpenVPN vir­tual net­work. Be­cause we don’t want any­body to know about this server, we can’t rely on DNS to iden­tify it. This means re­quests to Apache won’t have a server name as­so­ci­ated with them. To get Apache to re­spond without a server name, cre­ate the vir­tual host Vir­tu­alHost> by putting a file called “my­server.conf” in “/etc/ apache/vhosts.d,” with the same di­rec­tives that cur­rently work for the host you want to ac­cess. You should have Apache up and run­ning, and serv­ing up your web­site lo­cally, so just use the same di­rec­tives with the new Vir­tu­alHost. How­ever, you need to re­move the ServerName en­try, be­cause you aren’t ac­cess­ing the web­site with a server name. Now go to your lap­top, start OpenVPN, and type “” into your browser’s nav­i­ga­tion bar. Your su­per-se­cret web­site should ap­pear.

How­ever, we’ve only done this from be­hind the router. The third prob­lem is be­ing able to reach the server from out­side our net­work. For ex­am­ple, from a lo­cal bar or diner. Usu­ally, a host­name and IP ad­dress are con­nected though a DNS zone file. Or maybe you use a dy­namic DNS ser­vice. But we don’t want any­body to know about this server, so we can’t use ei­ther of these so­lu­tions. In prin­ci­ple, you can look at your router’s WAN IP ad­dress, but what if it changes? Here’s a slick way to ac­cess your server’s WAN IP ad­dress, even if it’s be­hind a router: dig

+short @re­ . Try it now on your own Linux ma­chine.

This com­mand is use­ful be­cause it can be put into your cron ta­ble and ex­e­cuted pe­ri­od­i­cally. Once a day is usu­ally more than enough, as ISPs don’t change their IP ad­dresses more fre­quently than that. Ours changes ev­ery few months. You can ssh into your server at any time, run the com­mand, then up­date the “re­mote” op­tion in the “client.conf” file if it changes.

Fur­ther­more, the out­put can be placed into a file and

trans­ferred to an­other server. For ex­am­ple, 0 */4 * * * dig +short @re­ >> ~/myip.txt; scp

~/myip.txt [email protected]­server: is a crontab en­try that grabs your IP ad­dress ev­ery four hours, puts it in a file, then sends the file to an­other server whose IP ad­dress doesn’t change—a VPS de­fined in your SSH con­fig file. This as­sumes a pass­word­less SSH key, and that the server is trusted.

Ad­di­tional se­cu­rity can be ob­tained by us­ing GPG to en­crypt the file be­fore trans­mis­sion. Now the file can be put on pub­lic servers without your IP ad­dress be­ing com­pro­mised. For ex­am­ple, the en­crypted file can be emailed to you au­to­mat­i­cally or put into Drop­box. Or in­deed, both. How­ever you want to do it, you can now de­ter­mine the IP ad­dress of your router at any time and change the re­mote op­tion in “/etc/openvpn/client. conf” to point to it.

When test­ing at home be­hind your router, use the ad­dress as­signed to your desk­top server. This en­ables test­ing with both the server and lap­top right in front of you. Once this is work­ing prop­erly, go out­side your home (or use a cell phone hotspot), con­nect to a pub­lic Wi-Fi, then test the con­nec­tion by chang­ing the IP ad­dress in the re­mote op­tion to the WAN IP ad­dress ob­tained from the dig com­mand above. Do­ing this leads us to prob­lem four: mak­ing sure you can ac­cess your server when it’s be­hind a router. For routers run­ning DD-WRT, it’s easy to set up. Go to the NAT/QoS ta­ble and look at the “Port For­ward­ing” tab. Port 1194 can be for­warded to the server run­ning OpenVPN [ Im­age D].

You’ve now set up a su­per-se­cret web server that no­body knows about and can’t be ob­served, be­cause of the OpenVPN en­cryp­tion. Note that this doesn’t for­ward all your In­ter­net traf­fic to your OpenVPN server—only the traf­fic be­tween your lap­top and the server.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.