DMZ Without the Risk - Part 3: Putting Everything Together

E

Eric Hansen

Guest
So now we have a VPN client, VPN server and now we’re ready to get our pseudo site-to-site network going. We’ll test this with a simple web server first. While I hate using it, for this purpose we’ll be using Apache and we’ll test both HTTP and HTTPS.

On the client machine lets install Apache:

Code:
root@SKYNet:/etc/openvpn# apt-get install apache2
Apache should auto-start on the client server, so visit your client machine via web browser and see if a web page shows up. Cool huh?

Well, we’ll take this a step further. Remember the inet address I told you to make note of in the last part? This is where it’ll come in handy. On the server we are going to mess with iptables a little bit.

We’ll enter two iptables commands on the server:

Code:
root@cs01:/etc/openvpn/easy-rsa# iptables -t nat -I PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.8.0.6:80
root@cs01:/etc/openvpn/easy-rsa# iptables -t nat -I POSTROUTING -j MASQUERADE
While I won’t get into a whole guide on how iptables works, basically since we want to forward traffic to another machine without ever concerning ourselves with it on the VPN server we need to use the NAT (network address translation) table. If you are familiar with basic iptables then PREROUTING can be compared to the INPUT chain and POSTROUTING compared to the OUTPUT chain. So everything on the server end we want to route to a client machine should go in the NAT’s PREROUTING chain.

For prerouting we are basically saying any traffic on TCP/80 is to be redirect to 10.8.0.6:80 (our client machine). if you set up Apache to run on a different port then you would just change “80” to whatever port its running on.

Now, I’m not going to pretend to be a guru with iptables (i.e.: man pages are my friend), but the postrouting table basically says “any packet leaving me will have my IP address”. Per the man pages themselves regarding MASQUERADE:
It should only be used with dynamically assigned IP (dialup) connections: if you have a static IP address, you should use the SNAT target. Masquerading is equivalent to specifying a mapping to the IP address of the interface the packet is going out, but also has the effect that connections are forgotten when the interface goes down. This is the correct behavior when the next dialup is unlikely to have the same interface address (and hence any established connections are lost anyway).
Since this is on a VPS it would be safe to do the SNAT route instead, but rather be on the safe side knowing how my luck with VPSes is. Basically, if you have a static IP it recommends using SNAT, otherwise use MASQUERADE.

What about HTTPS, though? Well, lets do that now! First, on the server we’ll add a new rule to iptables’ PREROUTING:

Code:
root@cs01:/etc/openvpn/easy-rsa# iptables -t nat -I PREROUTING -p tcp --dport 443 -j DNAT --to-destination 10.8.0.6:443
This is exactly the same and shouldn’t come to any surprise, either.

Now, on the client, we’ll need to generate some SSL information:

Code:
root@SKYNet:/etc/apache2# openssl genrsa -des3 -out server.key 1024
This will create a CA file of sorts. It’ll require you enter a passphrase. Since I’m lazy and this is only for demonstration purposes I just entered a short 4-character password. We’ll be removing it anyways (optional but less annoying if the server has to be restarted for any reason).

Next is a certificate signing request (CSR):

Code:
root@SKYNet:/etc/apache2# openssl req -new -key server.key -out server.csr
You’ll be prompted for the passphrase of the server.key file we just created so enter that, and I just allowed all the default values since you’ll get an SSL error regardless when you browse to it (its the fault of self-signed certificates period).

Here’s the optional step of removing the passphrase:

Code:
root@SKYNet:/etc/apache2# cp server.key server.key.org
root@SKYNet:/etc/apache2# openssl rsa -in server.key.org -out server.key
Enter pass phrase for server.key.org:
writing RSA key
Now you won’t be prompted for the passphrase.

To top off the certificate process we create the certificate itself:

Code:
root@SKYNet:/etc/apache2# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Lets make sure SSL is enabled for Apache (don’t restart it just yet):

Code:
root@SKYNet:/etc/apache2# a2enmod ssl
What we need to do is enable our SSL site so we don’t get cryptic errors in our log file:

Code:
root@SKYNet:/etc/apache2# ln -s /etc/apache2/sites-available/default-ssl /etc/apache2/sites-enabled/001-default-ssl
Now we’ll restart Apache:

Code:
root@SKYNet:/etc/apache2# service apache2 restart
Now when you browse to https://cs01.example.com you should see the same page as http://cs01.example.com!

There’s a multitude of applications for this (though not sure on using this for email purposes...have ran into issues). This is a great way to combat the threat of a DMZ and still provide security. You could also further increase the security of OpenVPN as well to help ensure data is left encrypted. This was just an overview.
 

Attachments

  • slide.jpg
    slide.jpg
    65.7 KB · Views: 137,005


This series is good, but you can do one thing that may help increase the number of views. At the top and/or of each article in a series, include hyperlinks to the other articles, then users can read an article and click one link to read the next.
 
This series is good, but you can do one thing that may help increase the number of views. At the top and/or of each article in a series, include hyperlinks to the other articles, then users can read an article and click one link to read the next.
I've thought about that, I'm just not sure if the links are static even after they've been made public. I think they are though, I'll have to pay more attention to the URI when I don't have a sinus headache and its sunny outside.

Thanks for the tip! :D
 

Members online

No members online now.

Latest posts

Top