DMZ Without the Risk - Part 3: Putting Everything Together

Discussion in 'Linux Networking' started by Eric Hansen, Oct 23, 2013.

  1. Eric Hansen

    Eric Hansen Moderator Staff Writer

    Messages:
    124
    Likes Received:
    87
    Trophy Points:
    28
    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:
    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.

    Attached Files:

    • slide.jpg
      slide.jpg
      File size:
      65.7 KB
      Views:
      135,854
    DevynCJohnson likes this.
  2. DevynCJohnson

    DevynCJohnson Well-Known Member Staff Member Staff Writer

    Messages:
    1,345
    Likes Received:
    1,083
    Trophy Points:
    113
    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.
  3. Eric Hansen

    Eric Hansen Moderator Staff Writer

    Messages:
    124
    Likes Received:
    87
    Trophy Points:
    28
    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
    DevynCJohnson likes this.

Share This Page