annabunches.net/content/posts/2008-12-06-paranoid-security-establishing.html

18 lines
23 KiB
HTML
Raw Normal View History

2016-04-11 22:01:00 +00:00
---
2016-05-04 18:41:25 +00:00
excerpt_separator: <br/>
category: technology
2016-04-11 22:01:00 +00:00
layout: post
title: 'Paranoid Security: Establishing a Connection the Hard Way'
date: '2008-12-06T21:03:00.000-05:00'
author: Anna Wiggins
tags:
- howto
- security
- linux
- Technology
modified_time: '2013-10-22T11:19:50.577-04:00'
blogger_id: tag:blogger.com,1999:blog-4209116010564764361.post-3958607884421991389
blogger_orig_url: http://www.stringofbits.net/2008/12/paranoid-security-establishing.html
---
Recently, I was describing the personal setup I use to connect to my home machine over on <a href="http://groups.google.com/group/watchingback/topics">watchingback</a> (a group that has gone unfortunately silent).  This setup combines <a href="http://en.wikipedia.org/wiki/Port_knocking">port-knocking</a> (with <a href="http://en.wikipedia.org/wiki/One-time_pad">one-time sequences</a>), disk encryption, and passphrase-protected rsa keys.  Here's a basic rundown of how it works from an end-user perspective (i.e., once everything is set up):<br/><br/>First, the user (me) inserts a USB flash drive with an encrypted partition.  He mounts up the encrypted disk on a local machine (I'll call this machine the 'client' throughout this article), providing the necessary password, and runs a script called 'callhome'.  He is prompted for his passphrase, and then gets a terminal session on his home machine (we'll call this one the 'server').<br/><br/>Read on for details about this setup, and how to do it.<br/><br/><a name='more'></a><br/><br/>Warning: what follows is madness. It is overkill taken to an extreme.  I am describing a way you can take a very, very simple procedure (connecting remotely to a system), and make it exceedingly complicated, all for the benefit of a little added security.  Whether or not this security is worthwhile to you is, of course, your business.  In an age where our governments and fellow citizens are increasingly keen on everything from our shopping and reading habits to our credit card numbers, I personally feel that cautiousness is worth the effort.<br/><br/>It is madness.  I'm not convinced it isn't justified madness.<br/><br/>This tutorial assumes you are running <a href="http://linux.org">Linux</a>, and that you are comfortable with the command-line interface and with networked computing in general (of course, you're reading this on the Internet, so that's a good start).  All of my examples will be <a href="http://fedoraproject.org">Fedora</a>-centric.  If you don't use Fedora, you'll need to figure out what the commands are for your distro.<br/><br/>So, how is this complex setup I describe different from just typing "ssh user@server"?  Well, first, the callhome script executes a portknocking sequence.  Until this sequence is done, ssh is closed on the server.  After the sequence, ssh is opened only for the IP address of the client, and only for a small time window.  The ssh connection must happen during this window.  The script initiates the ssh connection, which helps keep this secure.  In addition, each portknocking sequence is valid only once - the USB drive contains a list of all valid sequences, and the script is set up to only use each one once.<br/><br/>Next, ssh on our server is set up to <strong>only</strong> allow connections with public keys.  This means that even if an attacker knew the correct portknocking sequence, he would not be able to login with a password - he must have the private RSA key.  The private key is on our USB flash drive, which is encrypted.  The key itself is further encrypted with its own passphrase, so you still enter a password to connect home, the work to verify it is simply done on the local machine.  The passphrase is never sent across the Internet, even in an encrypted/hashed form.<br/><br/>There are some other nice features, including a 'panic' portknocking sequence that will shut down the portknocking server itself, locking down the remote server completely.  This panic script is stored on a machine to which I have a shell account.  If the USB flash drive is ever lost/stolen, I can get to any machine with an ssh client, log in to the shell account, and kill the knock server.  New connections to the server then become impossible.<br/><br/>This setup is useful for more than just a terminal connection home.  You can forward X through it and run graphical apps from home (this is typically going to be very slow, however).  You can forward any ports you like, so that you can route web traffic through this ssh tunnel and prevent people on you