Secure Function: Findings, musings, how-tos, and analysis

Pritunl for AWS VPC with Replicated Servers

After doing some research on VPN alternatives to using AWS’ provided VPN options I recently settled on doing a test with the software Pritunl. The software is an open-source GUI frontend for OpenVPN. It does a nice job of simplifying the management and configuration of the VPN endpoints and, when you pay for Pritunl Enterprise, also includes some other nifty features.

There are several features that are unlocked by paying for the Enterprise license and one of those is Replicated Servers. Replicated Servers gives you a unified backend database (using MongoDB) that stores configuration and user information. This lets you run multiple Pritunl hosts for your users to provide extra endpoints in the event of a failure.

The setup is pretty simple but since I didn’t see any articles or posts covering the setup so I thought it would be good to go ahead and put something together. In this case I’ll be using AWS but the principals are the same no matter where the hosts are.

For this example we’ll be using Ubuntu Server to keep things more provider-agnostic. It’s possible to use Arch Linux or Amazon Linux instead if you prefer that.

First, of course, you’ll need to be logged into the AWS console or have the CLI set up on your machine.

Go ahead and allocate 3 Elastic IPs in your VPC. We’ll use two for the internet-facing hosts and the last will be a way to provide a static IP for the database host. You can use other methods to make the IP stick but this one is the simplest and it allows the host to update from the web.

Set up two EC2 security groups:

  • VPN:
    • TCP/22 open to your IP for SSH
    • TCP/9700 open to your IP for access to the web UI (you may want to open this to /0 later)
    • UDP 25000 open to 0.0.0.0/0 for the VPN tunnel
  • VPN DB:
    • TCP/22 open to your IP for SSH (you may want to remove this or limit it later on)
    • TCP 27017 open to the VPN SG for the database connection

We’ll start with the database host first. Go ahead and start an instance of the size that suits your deployment and use Ubuntu Server 14.04. You’ll probably want to put this in your private subnet if you have one. Make sure you have set the security group up as above. Assign one of the EIPs to the host and go ahead and connect over SSH.

Once logged in you’ll want to execute the following commands:

Woohoo! Our database lives!

Next let’s start the Pritunl VPN hosts. You can start as many or as few as you need and with the size that suits best but again use Ubuntu Server 14.04. These should be in your public subnet. Assign EIPs for each. Then go ahead and connect over SSH.

For each machine do the following:

You’ll then need to open your browser to https://<host IP>:9700/ and fill in the MongoDB host information. On the first host you’ll then log in with the default user/password of pritunl/pritunl, change the login, and then enter your Enterprise license key. After that log in to each of the rest of the hosts and enter the MongoDB host information.

Now with that finished we have replicated Pritunl configured. Not including bandwidth or the discounts of reserved instances it can be about $90/month for this setup using two t2.micro instances for the VPC endpoints and a t2.small for the MongoDB host. So far in testing I’ve successfully pushed greater than 25mbps through a connection on the t2.micro host without any fuss.

The next step involves a little planning. Consider what parts of the network different user groups will need to access. If everyone will have access to everything in your VPC this is easy but otherwise you’ll need to plan for which subnets people need access to. This could mean splitting things up by teams or maybe just production access accounts versus nonproduction access.

Go to the Users tab. You’ll want to create one or more Organizations for users to be grouped into. For each different group that needs access to different subnets you’ll want different organizations. After that go ahead and put the users in their correct organizations. With Pritunl Enterprise you can use SSO to handle part of this but that’s something to cover another time.

At this point you can set up your first Pritunl sever. In the web interface one one of the hosts go to the Servers tab. There click on the Add Server button and fill out the form. For the UDP port enter 25000 (that we added to the EC2 SG earlier). Make sure to click on the Advanced button and enter the number of replicated hosts you’ll use for the connections. You’ll also want to change the server mode to Local Traffic Only and specify what subnets the VPN server should give access to. Once satisfied with the config click Add and then watch the UI. The server will generate it’s DH parameters in the background. If you’ve selected parameters more complex than the default 1536 it’s going to take a little bit to finish. I’d recommend you use at least 2048.

You can start making additional servers for each set of subnets people might need to access. Associate the organizations to each based on their needs.

Once that’s all done and all of the DH parameters have been generated you can start the servers. After they’ve started you can download the credentials for your user and confirm that the VPN responds as it should.

You should now be all set; distribute the credentials needed to all of your users and enjoy.

Update:
Below is the script I run on the Mongo box to back it up each night and drop the results into S3.

Shell Script: Use Twitter and Bing to Generate Wordlists

There are some great wordlists out there for sure… but a targeted wordlist that fits with the subject of the target site/database can prove to be much more effective.  Joshua Dustin posted to his blog recently about this and I thought this was an excellent idea and wanted to take it a little bit further.  This script adds some automation to his idea and also adds a word-grab from Bing as well.  Since it’s a little more modularized in this script it’ll be easy to add other word sources.  I’ll be adding more soon once I have additional time to do so.  Please check out his post for further information on why this type of wordlist generation can be so effective.  He does a great job explaining it.

I have a few other things in the works I had intended on releasing sooner (rather than another post based on someone else’ idea) but those scripts are getting near-daily updates due to the fact that I’m using them constantly.  One just got a roughly 20x speed boost today thanks to some command-line option changes.  Don’t worry, though, they’re worth the wait!  Now, on to the code;

Running this script:

  • Run it using as many keywords as you’d like to scrape off the web:
    • # ./wordlistgen.sh your keywords go here

More Information:

Secure Browsing From Anywhere

Do you trust the wifi you’re using at Starbucks?  Maybe that hardline at the hotel is sketchy.  You never know who is on the network with you and what their skills and motivations might be.  Why share anything with them if you don’t have to?  What the sections below cover is setting up a secure proxy server that you have control of to allow you to surf the internet on even the most questionable connections without having to worry about eavesdroppers and MITM attacks.  We’ll set up a linux server, SSH with certificate authentication, and then start browsing through an encrypted tunnel.  Your SSHD options may dictate another setting but typically this tunnel will be secured with AES-256 which is a secure and fast cypher.  AES-256 is what’s used with other encrypted storage or communications like BitLocker, IronKey devices, and SSL.

This does assume that you have some technical background already but I tried to make things pretty easy.  If there are any questions please add them in the comments and I can try to answer there or add them into the post.

The first section below covers the setup and initial configuration of the proxy server.  In this example we’re using a linux server and the Squid proxy.  Linux natively supports SSH for the encrypted tunnel and Squid is an excellent open-source proxy solution that also provides web caching.  You can set up a similar solution using SSH via a Windows server but it requires a more involved setup process as SSH isn’t natively a part of the Windows OS.

The second section describes the client setup and use from either linux or Windows.  The linux instructions should work for Mac users as well.  Once the proxy is up and online using it from your client system is easy and straightforward.

The third section is optional as it’s additional configuration that doesn’t have a major technical effect as we’ve already encrypted everything but what it does to is prevent the sites your visiting from knowing you’re even using a proxy.  The possible implications of that would be altered behavior of the site due to your IP being identified as from another nation or similar.  For example, some sites limit your access based on your location because of copyright reasons. While this is not meant to be an assist to violating copyrights that ability is there.  The goal for me in this was being able to get US internet while abroad.  I can’t watch Netflix movies from Europe on my US Netflix account but it works well when I pass my traffic via my transparent US proxy server.

In the last section I’ll address an additional configuration option for Firefox that will also prevent information leakage via your DNS requests.  What the setting does is tell Firefox to forward DNS requests to the proxy server to answer rather than querying the DNS server your client system is pointed to.  This means that if an attacker is listening on the wire they are unable to see what sites you’re browsing based on your DNS queries.

If you don’t have a handy dandy home linux server like I do then you’ll want to get one set up or use a cloud provider.  Amazon Web Services provides an intro tier that gives you enough free utilization to run a small linux server for a year and a fair amount of bandwidth along with several other services.  You can sign up for this at https://aws.amazon.com/free  Just keep an eye on your bandwidth usage and you can use it 100% free.  It’s cheap after you get out of the free tier but keep in mind it does cost money if you use more than the allotted free amount.  Beyond that there are other options (all paid) by using Linode, Rackspace, or others.  There’s no option for a linux server with Azure (yet?) so don’t try there unless you want to try to set this up on Windows.

 

Note:  These instructions assume that they are run as an administrative user such as root.  If you will be using a non-administrative user with sudo rights just keep in mind most of these commands require sudo first.  Also, note that the instructions below are based on completing this on Ubuntu, Arch, or Fedora.  The packages specific to your system may vary slightly if you’re using another distribution.  You can check the online references or package lists to verify which package is right for you.

 

Part 1: Server Setup (Linux)

1. Make sure your server’s firewall is secure. You’re going to be installing a proxy server and you don’t want the world trying to use it. How you choose to do this is up to you but IPTables is a solid option.  Make sure, however, that you are careful with the rules or your own connections will be blocked as well.  If there’s interest I’ll add an IPTables how-to onto here as well.  If you are using an AWS VM the default setting is very secure as it doesn’t allow anything through you haven’t already specified.  If you haven’t done so already make sure the server is up to date as well.  Example: apt-get upgrade or yum update or pacman -Syu

2. Install SSH if not already present. Example: apt-get install openssh-server or yum install openssh-server or pacman -S openssh

3. Set up SSHD. You can find the config usually in /etc/ssh/sshd_config.  Example:  nano /etc/ssh/sshd_config
— a. Set port to something high and/or unusual like 45454
— b. Disable password authentication.
— c. Disable remote root login
— d. Enable logging to SYSLOG for all AUTH if not already enabled
— e. Ensure RSA logins are enabled and using .ssh/authorized_keys or another to your preference.  Here I will assume .ssh/authorized_keys

4. Create a new user on the system. I recommend using -m to create the home directory in advance.  If you’d like to be able to use this account for administrative functions you can also use -G to specify the group the user should belong to.  For Ubuntu you would use the second example provided.  Example:  useradd -m newuser  Example 2:  useradd -Gm newuser,wheel

5. Use ssh-keygen to generate an ssh key for this user. I recommend using -b 4096 -t rsa to use a 4096bit RSA certificate.  Example:  ssh-keygen -b 4096 -t rsa

6. Copy the public key into the users authorized key file. Create the file and folder if needed. Example: cat newuserkey.pub > /home/newuser/.ssh/authorized_keys

7. Use chmod to change the permissions of the file to 0600 so it is recognized by SSHD.  Example: chmod 0600 /home/newuser/.ssh/authorized_keys

8. Copy the private key to the system you’ll be connecting from.  Make sure you name it something obvious so you’ll be able to find it again.  Example:  newuserkey.pem

9. Start/restart SSHD. If SSHD is running use /etc/rc.d/sshd restart or /etc/init.d/sshd start or service sshd restart. Which works will depend on your distro.  If not running use start instead of restart.

10. From the other system use PuTTy or SSH to test the connection and make sure it works and the key works. If you’re not familiar with this process use the instructions in Part 2.  Example: ssh -i newuser.pem newuser@server -p 45454

11. Once SSHD is verified go back to the server and install Squid. Example: yum install squid or apt-get install squid or pacman -S squid

12. The Squid default config will be fine for our purposes but you can harden it by editing /etc/squid/squid.conf or wherever you installed to.

13. Start Squid. Example: /etc/rc.d/squid start or /etc/init.d/squid start or service squid start

14. Use chkconfig to verify the services for Squid and SSH start automatically.  Run  chkconfig   to see the current setting.
•  a. If one of both of the services aren’t set to on at any run level you can fix that also using chkconfig.
•  b. To start Squid automatically use the first example.  The second is for SSHD.  Example:  chkconfig –level 2345 squid on Example 2:  chkconfig –level 2345 sshd on

16. Validate that the firewall between this system and the internet allows incoming connections on the port you chose.

 

Part 2: Using your new RSA encrypted secure proxy

Part 2a: Linux Client system

1. From a remote site verify you have internet connectivity.

2. Verify that SSH back to your server is working. Example: ssh -i newuserkey.pem newuser@server -p 45454

3. Disconnect and reconnect with tunneling enabled targeting the Squid port. Example: ssh -i newuserkey.pem -L 8080:localhost:3128 newuser@server -p 45454

4. Open your browser and change the proxy setting to 127.0.0.1:8080.  In Firefox this is in Options -> Advanced -> Network -> Settings

5. Attempt to open a web site. You should be able to browse like normal.

6. Congrats! You are now browsing inside an encrypted tunnel!

Part 2b: Windows Client Cygwin Method

1. From a remote site verify you have internet connectivity.

2. Install Cygwin from  http://www.cygwin.com/install.html

3. Open the Cygwin terminal and verify that SSH back to your server is working. Example:  ssh -i newuserkey.pem newuser@server -p 45454

4. If that succeeds disconnect (just type exit) and reconnect with tunneling enabled targeting the Squid port.  Example:  ssh -i newuserkey.pem -L 8080:localhost:3128newuser@server -p 45454

5. Open your browser and change the proxy setting to 127.0.0.1:8080 for all protocols.  In Firefox this is in Options -> Advanced -> Network -> Settings

6. Attempt to open a web site. You should be able to browse like normal.

7. Congrats! You are now browsing inside an encrypted tunnel!

Part 2c: Windows Client PuTTy Method

1. From a remote site verify you have internet connectivity.

2. Install Putty using the Windows installer from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

3. Open up PuTTyGen and import your newuserkey.pem certificate file.

4. Save the new PuTTy formatted key by clicking Save Private Key. You can ignore the prompt about not passwording the file.  It will now have a PPK extension and look like newuserkey.ppk

5. Open the main PuTTy program and type or paste in the server’s DNS name or IP and correct the port number to the one you set SSHD to.

6. In the left-side menu select SSH and then Auth to get to the SSH Authorization section.  Click browse next to Private Key File For Authentication and select your newuserkey.ppk file.

7. At the bottom of the window type in a name for the config and click Save and then Connect to test the connection.

8. If that succeeds disconnect (just type exit) and reopen PuTTy.

9. Once PuTTy is open select your saved config and click on Load.

10. Now that your config is loaded use the left-side menu to select SSH and then tunnels

11. Type in 8080 in the source port and for destination use 127.0.0.1:3128 and click Add.

12. Click on Session at the top of the menu and click Save to save your updated config.

13. Click on connect to start a new SSH connection to the server.

14. Open your browser and change the proxy setting to 127.0.0.1:8080 for all protocols.  In Firefox this is in Options -> Advanced -> Network -> Settings

15. Attempt to open a web site. You should be able to browse like normal.

16. Congrats! You are now browsing inside an encrypted tunnel!

 

Part 3:  Hide the proxy flags (optional)

1. Open your Squid config file for editing (Example: nano /etc/squid/squid.conf) and add the following lines to the bottom:

Squid 2.x:

via off
follow_x_forwarded_for deny all
forwarded_for delete
request_header_access From deny all
request_header_access Server deny all
request_header_access WWW-Authenticate deny all
request_header_access Link deny all

Squid 3.x:

via off
forwarded_for delete
request_header_access X-Forwarded-For deny all
request_header_access From deny all
request_header_access Server deny all
request_header_access WWW-Authenticate deny all
request_header_access Link deny all

 

Part 4:  Extra Firefox Settings (all clients)

1. Open up Firefox and in the URL bar type in about:config

2. Find the setting network.proxy.socks_remote_dns and change the value to true

 

More Information:

© 2017 Secure() All Rights Reserved