

Secure your code: OpenVPN in the cloud - trefn
http://code.mixpanel.com/openvpn-in-the-rackspace-cloud/

======
tptacek
I'm not totally wild about OpenVPN. If you asked me which I'd rather expose,
SSH or OpenVPN, I'd have to flip a coin. In either case, it's easy to realize
the "right" configuration, with a single "bastion" host (hate that word) that
provides authorized clients with transparent access to servers.

One thing you can say for SSH is that it gets a lot more audit attention than
OpenVPN does.

In either case, the problem I think most startups should move to solve early
is multi-factor authentication. I have friends building things with Yubikeys,
and others building things with SMS-based auth; either are better than
straight passwords, which are (among other things) a policy nightmare.

~~~
CrLf
OpenVPN can be configured to be stealthy (to start a connection, the first
packet must be signed with a shared-secret, otherwise it doesn't respond),
while SSH doesn't. And OpenVPN has the performance advantage (tunneling is
done over UDP instead of SSH's TCP - TCP over TCP brings about a couple of
performance problems, especially when there's congestion).

~~~
tptacek
The whole stealth thing (and "port knocking" along with it) is wildly
overrated. If your security depends on people not knowing you're running SSH
or OpenVPN, you have bigger problems.

If you want to get all cutesy, go hack SSH to add an extra round or two to
OpenSSL's AES. That'll learn 'em.

~~~
dododo
it depends upon your threat model.

there's probably a bug in some code on your system that's exploitable. maybe
openvpn or ssh or its configuration (c.f., debian crypto bug).

under this model, anything that increases the time til (inevitable, under this
threat model) success, works.

running ssh or openvpn on a different port or whatever to "hide" it, will help
against mass scans for common exploits. it increases the work to find the
problem. of course it won't really help against a concerted, targeted attack.
but i'm pretty sure unskilled, mass attacks are more common than targeted
attacks.

~~~
tptacek
The guy with the OpenVPN zero day probably isn't getting slowed down by your
stealth configuration. At least, that's how my threat model works.

If you believe in stuff like this, then do it right: require the attacker to
know a secret algorithm (like "AES with 3 extra rounds") to talk to you.

~~~
dododo
does the guy with zero day want to:

1\. break into your machine?

2\. break into some machine?

if (1) then i certainly agree that none of this really matters (i apologise if
that wasn't clear from my previous comment).

on the other hand, if his objective is (2), and not everyone is using some of
this obfuscation, then this separates you from the crowd for a little while
(but my model is that as time goes on, you are inevitably exploited).

i realise after your company was exploited it might make you feel like (1) is
always the case but for many (2) is the salient threat.

~~~
tptacek
Generally speaking, the people running around with OpenVPN and SSH zero day
are looking to break into _your_ machine. The people looking to break into
_any_ machine are either targeting Windows clientsides, or weeks-to-months-old
web vulnerabilities.

People with SSH zero-day are not, by and large, looking to burn those
vulnerabilities by spraying them into every busybody's honey pot logs.

~~~
iuguy
> The people looking to break into any machine are either targeting Windows
> clientsides, or weeks-to-months-old web vulnerabilities.

Actually the people looking to break into your machine are targeting windows
clientsides and weeks-to-months-old web vulnerabilities.

There's a cost involved in developing 0day, droppers, remote access trojans,
maintaining breach and exfil teams etc. If these guys can get into the
developer laptops with an email, a wink and a PDF then why waste the 0day? If
you're putting all your effort into a custom SSH daemon without expending
equivalent effort on your connection sources (especially when connecting to
the Internet) then you're doing it wrong.

------
dugmartin
We have been using OpenVPN to secure one of our Rackspace servers dedicated to
development for the last couple of years. We also have ejabberd running on
that box (just talking to the vpn interface). It works great for distributed
development and the internal secured jabber IMs are great for transferring
sensitive stuff like passwords between remote folks. We also have a persistent
conference room for a shared "watercooler".

The main problem we have is key management. Does anyone know of a good admin
app for generating, storing and revoking keys?

~~~
trafficlight
Are you still generating keys by hand or have you found something that works a
bit better?

I've been looking around for an admin app as well. It would be even better if
I could tie it into an intranet site as well.

------
aguynamedben
tinc is really good little secret I have found if you want a true mesh P2P
secure overlay network. It's open source, has a good community in freenode
#tinc, and really easy to install and use, just read the man page
<http://linux.die.net/man/5/tinc.conf>

<http://tinc-vpn.org/>

~~~
pilif
can you tell me what the actual difference between OpenVPN and tinc is? I know
OpenVPN very well and really like it. Why would I prefer tinc over OpenVPN (or
the other way around)?

In my opinion, they share a lot of the same features like running in
userspace, easy configuration, ssl/certificate based authentication - just the
same.

~~~
mike-cardwell
Front page of the project website:

"Automatic full mesh routing. Regardless of how you set up the tinc daemons to
connect to each other, VPN traffic is always (if possible) sent directly to
the destination, without going through intermediate hop"

OpenVPN doesn't do that, and it sounds very useful when multiple machines are
involved

------
ritonlajoie
we are doing that in our production environment. We use different boxes (1 on
US and 2 on EU), they are connected with openvpn to serv our different needs.

Our personal development boxes are also connected to each others using OPENVPN
and firewalled. All the internal code made for our app is using the VPN ips,
and every application is listening on these IP only (not localhost nor
0.0.0.0)

(applications are mysql/couchdb/git/apache)

That's pretty great !

------
trun
I was just looking for something like this, literally about 30 seconds before
you posted it. Thanks!

------
steve19
My problem with OpenVPN is that you cannot access it from an iPhone.

------
pmjordan
The diagram has connection lines between all nodes; does this imply N² point-
to-point OpenVPN connections, with a subnet for each connection?

~~~
trefn
The lines between the nodes were actually meant to show that those nodes use
the Rackspace internal network (ServiceNet) for communication - see the
colored labels on the diagram.

~~~
pmjordan
Ohh, I see, blue = unencrypted. That makes sense, thanks. So there really
isn't any gain over using SSH with private key authentication with this?

~~~
mseebach
Yeah, there is. First, doing it with SSH+keys requires either multi-step
(which is annoying, esp. for copying files), or exposing each servers SSH to
the net (which might be unfeasible if you don't have public IPs for
everything).

Second, getting a dump of a table from your MySQL DB with SSH+keys:

    
    
      ssh prod-db 
      mysqldump what-i-need > file.sql
      exit
      scp prod-db:file.sql .
    

With VPN (assuming the connection is running):

    
    
      mysqldump -h prod-db whatever > file.sql
    

(I'm not saying it's neccesarily a good idea to du dumps of your production
db, but that was the example that came to mind.)

There's also stuff like instrumenting a running Tomcat with JVisualVM on a
server in your remote environment (which, no, you can't easily do over SSH-
forwarded ports.. also, portforwarding is annoying).

Finally, VPN allows you to run internal services. A jabber-server was
mentioned in the article, and perhaps a webserver with some reports/dashboard
thing, cacti/nagios stuff etc. without worrying about setting up
authentication and SSL for each. Each VPN user gets his own IP, so you can
just do crude IP allow/deny if you need, or you can put the customer people on
one subnet and allow them to access the reports server, and the devs/ops on
another that can reach everything.

~~~
noste
While I think you're right in that VPN setups make a lot of things smoother,
SSH actually compares pretty well with the first two of your examples.

"Yeah, there is. First, doing it with SSH+keys requires either multi-step
(which is annoying, esp. for copying files), or exposing each servers SSH to
the net (which might be unfeasible if you don't have public IPs for
everything)."

You can work around much of the annoying stuff in multi-step setups by using
SSH's ProxyCommand configuration variable. For example, you could have
something like this in your local .ssh/config:

    
    
      Host prod-db
        ProxyCommand ssh bastion nc -w1 %h %p
    

After which 'ssh prod-db' and 'scp prod-db:...' work as if the bastion host
wasn't between you and prod-db.

"Second, getting a dump of a table from your MySQL DB with SSH+keys:"

If you can access prod-db with SSH, you can dump the database with a single
command:

    
    
      $ ssh prod-db mysqldump what-i-need > file.sql

