Elastic IPSEC with Andrew Mulholland 

andrew mulholland @itwasntandy

traditional: devices at the edge

  • like the titanic – one breach will do it

91% of hcos had 1 data breach in the last 2 years

co-worker was owned – there was an error in a process called “exploit”

encryption in trasit
SSL: plenty of people with bad SSL certs
ssllabs.com
cipherli.st
cisecurity.org
letsencrypt.org
hardening.io

encryption inside the perimeter is totally possible

client cert mutual tls

  • high overhead for dev / ops
  • cert management is a pain, need a security store

** aside: cert of smtp.gmail.com expired because intermediate cert expired for 2 hours

make it automatic:

  • wrap all HTTP in TLS
  • or make it part of your infra

kafka only recent TLS support

“full mesh” – p2p ipsec for everything

previous approach:

  • trusted CA
  • chef search populated the conf on all machines

pagerduty / velocity conf recently discussed similar

problems:

  • autoscaling does not work
  • relies on certs (10 year exp, but ca expired)
  • config was unwieldy

using chef

  • can use it to establish trust relationship
  • generate raw rsa keys (not certs, no expiry)
  • populate to all nodes

works with autoscaling

libreswan uses NSS for storing keys
chef generates key
pushes the public key to s3
subsequent runs nodes pull down key

chef -z: zero runs locally

for each host, template the IPSec tunnel with the public key from the S3 bucket
req ipsec service restart

prove you’re on an encrypted channel:
sudo tcpdump -nnv host xxxx
pint from xxxx
see pings not from icmp

iptables to restrict
src 0.0.0.0 dst 0.0.0.0
iptables set esp req mode transport

only triggers iptables restart on add/remove of hosts

uses iam ec2 role to

get/list from s3
allow put to all /pub_keys/

idea: use IAM magic variable to allow upload to /pub_keys/{instance id}.pub