Proxy tools and configs to exist in corp land and at home

Preface

Let’s face it, having a corporate proxy with NTLM based authentication really sucks. The forced authentication to an AD backed directory makes sense but creates pain when you work in a terminal and unix/linux world. Thankfully over the past decade or so some amazing people have created some tooling to help navigate the NTLM proxy landscape. Among these tools, cntlm is a fantastic solution to this problem. While cntlm solves 90% of your problems, that last 10% involves turning proxy settings off easily when you are away from the office. There are some sophisticated ways to solve the in-office/out-of-office settings detection dilemma, but I have opted for a “simple” one which was inspired from a ServerFault post (http://serverfault.com/questions/506046/configure-cntlm-to-use-no-proxy-if-none-are-available).

The solution presented here assumes the following:

  • Stuck using Windows 7/10 as your host OS
    • Note: If you have the luxury of using Mac OSX as a host OS, then also try Fiddler
  • Stuck with a corporate NTLM authenticated proxy
  • Using Virtualbox for development and virtualization tooling
  • Using a Linux VM in Virtualbox
  • Desire to seamlessly move in and out of corp offices and home without the need to edit the cntlm.ini or autodetect network locations
  • You have local admin privileges

Solution Design

  • Cntlm configured with:
    1. Corp proxy
    2. Local squid proxy on alternative port
  • Linux VM bash profile configured to use the cntlm proxy

Functionality

  • When connected to the corp proxy, the connections will use it via the authentication creds configured in cntlm
  • When at home or away from the office, connections will first try the corp proxy, then failover to the 2nd local squid proxy which uses a direct internet connection

This makes things simple and you dont have to change all your proxy settings all the time. Just use the local cntlm proxy and it will provide seamless functionality for out of office non-proxy direct connections by failing over to the local squid proxy. There is a downside to having to install the squid proxy and do the extra configuration, but it works nicely once setup.

Components

  • Cntlm.ini file pre-configured, but you need to add your user account and password hash, domain, and proxy
  • Squid.conf pre-configured to bind to port 3129
  • Example .bash_profile relevant config parts
  • Example yum/apt/dnf config
  • Example wget config

Pre-requisites:
Cntlm
Squid for Windows)

Operations

  1. Launch Squid proxy (use Windows services or Squid systray tool)
  2. Start Cntlm from administrator enabled command prompt:  net start cntlm

Get Configs

https://github.com/jbpadgett/proxy_tools

  • Cntlm.ini file
  • Squid.conf pre-configured to bind to port 3129
  • Example .bash_profile relevant config parts
  • Example yum/apt/dnf config
  • Example wget config

Path it your way

I really like the cool products the team at HashiCorp cook up.  Unless you have been frozen in carbonite for the past 3+ years, you’ve likely used or heard about Vagrant.  What a wonderful tool that lets you rapidly build and test on VMs and containers on VMs using Virtualbox.  As if that wasn’t awesome enough, this past year Mitchell and his team have introduced multiple awesome projects including terraform, consul, serf, and packer.  I wanted to get my hands on these tools and use them locally on my Mac.  As with Vagrant, each of these products are packaged into a nice downloadable binary which you can then extract to the directory of your choice for use.   However, after reading the documentation carefully, you’ll find that setting your path to these executables is a key part of your environment setup.

Setting path variables is not a big deal at all.  However, I wanted all my HashiCorp products executables to live in a specific directory configuration.

mkdir -p $HOME/hashicorp/{consul,packer,serf,terraform}

$tree $HOME/hashicorp -d
/$HOME/hashicorp
├── consul
├── packer
├── serf
└── terraform

Since there are multiple projects from the same company to be used, I wanted each one in its own subdirectory.  Rather than list each HashiCorp product in my .bash_profile PATH statements, and to prevent other things from getting broken in the process of editing the paths (RVM, etc), I decided to dig around on our good ole friend StackExchange and found some good tips for doing paths for multiple subdirectories.

So, I did the following in .bash_profile to have the shell iterate over each subdirectory and add to the $PATH export.

$vim .bash_profile
# HASHICORP PATHS
for p in $HOME/hashicorp/*/; do
 export HASHIPATH="$p"
 PATH="$PATH:$HASHIPATH"
done

Note: It is likely a security anti-pattern to have recursive paths if I were to get malicious code from Hashicorp since I am setting up a specific path root for all the tools from them I intend to drop into this directory structure. Again, this structure is just a personal preference to keep everything in a single root directory with release versions. I could have chosen to do symlinks or symlink tools like stow, but I just wanted something quick and functional with the directory structure I desired.

Now, the next awesome product that the folks at HashiCorp release that I want to use, I can simply drop it into the subdirectory of my choice with the versioning directory I like, and I’m good to go.