Ex. https://www.dnsleaktest.com/

We should print out some instructions at the end of the script to help users ensure they have their devices setup correctly. All traffic should go through the VPN.

After we get everything working, we should try to trim down the StrongSwan binaries as much as possible by compiling from source and disabling everything we don't use. As a side benefit, this makes it a more unique target for exploitation and ensures that we're using the latest version.

Here my initial review of Autoconf options:

Enable new good features:
--enable-chapoly
--enable-gcm
--enable-openssl
--enable-rdrand

Enable testing support
--enable-conftest
--enable-integrity-test
--enable-test-vectors

Disable legacy ciphers
--disable-cmac
--disable-des
--disable-ikev1
--disable-md5
--disable-rc2
--disable-sha1
--disable-xcbc

Disable unused features
--disable-attr
--disable-dnskey
--disable-pgp
--disable-pkcs1
--disable-pkcs7
--disable-pkcs8
--disable-resolve
--disable-scepclient
--disable-sshkey
--disable-xauth-generic

We'll also need to figure out package signing and write a script to automate this somehow:

• PPA Guide

We may be able to limit the privileges of the strongSwan daemon even further by running StrongSwan as a non-root user and then limiting it to cap_net_admin. cap_new_raw may be required if we use connmark since it's required by the iptables library that plugin uses.

Strongswan ipsec.conf client templates for linux or other platforms with strong cipher enforcement, etc, etc.

Apple devices (OS X and iOS) can be automatically configured with mobileconfig files. We should generate one of these files for the user to auto-configure the VPN for their system. There is some more info about this in the StrongSwan documentation.

I have a working mobileconfig file I can share. We can probably add some Jinja2 templates to it and replace the values no problem.

https://stackoverflow.com/questions/9683279/make-the-current-commit-the-only-initial-commit-in-a-git-repository/9683337#9683337

https://github.com/ValdikSS/easy-rsa-ipsec

Cheatsheet:

• ./easyrsa init-pki
• ./easyrsa build-ca nopass
• ./easyrsa gen-req dan nopass
• ./easyrsa sign-req client dan

OR

• ./easyrsa build-client-full ryan nopass
• ./easyrsa gen-crl
• ./easyrsa gen-dh

Alternatives:

• https://wiki.strongswan.org/projects/1/wiki/SimpleCA
• https://wiki.strongswan.org/projects/1/wiki/IpsecPKI

Either way, it should be as easy as possible for the administrator to enroll new users to their VPN. We should help the administrator create and sign a certificate, then generate a new mobileconfig file to provide to the user.

There is currently no ENI check for the EC2 playbook.
If you have not deployed an EC2 instance in a zone previously, then a default network interface will not exist in the zone and EC2 deployment will currently fail.

The EC2 playbook is using the default users-management inventory.

While this is fine for now, in the future support for dynamic inventories with the user management playbook should be integrated. Not just for EC2 but for all providers.

For users that want to use this project as their corporate VPN, add some helper scripts for user management.

The features role really has 2 separate, self-contained services: dns_adblocking and proxies. We should take all of dnsmasq and put it in a role called 'dns_adblocking' and put apache and privoxy into a 'proxy' role by themselves.

https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

This is really hard to figure out and might require looking through the AOSP source code or talking with someone else who has. This looks like it might work:

Encryption: aes128gcm16
Integrity: sha256
DH Group: ecp256

https://github.com/trailofbits/algo/blob/master/config.cfg#L17
https://github.com/trailofbits/algo/blob/master/config.cfg#L27
https://github.com/trailofbits/algo/blob/master/inventory#L5
https://github.com/trailofbits/algo/blob/master/inventory_users#L2

Nothing too crazy, let's try to block some of the worst types of advertising with a configuration for the proxy. It should auto-update on a regular basis with a cron job.

We support "remote" installation where we provide the IP and a username to access a device. However, "local" installation is where the user has downloaded algo directly to the server they want to install to. In this mode of installation, there is no need to use SSH.

There are a few issues to overcome to support running the playbooks directly on the target server:

1. The UI for initial installation and user management. We want to keep both of them as simple as possible. That means avoid creating new options where possible.
2. The documentation. We need to add something to the readme that is easy to understand. In order to install algo on Ubuntu locally, you need to install ansible first. Installing ansible via pip requires pulling in a lot of dependencies, including a full compiler suite. It is easier to use apt, however, Ubuntu 16.04 only comes with ansible 2.0.0.2. Therefore, to use apt you must use the ansible PPA and using a PPA requires installing software-properties-common.
3. The bash script does not run in Ubuntu 16.04. /bin/sh on Ubuntu is the dash shell, not bash, and the -s option is not valid. We need to edit the run script to deploy from Ubuntu. The one place in particular where we run into this issue is prompting for the certificate password, which we could remove from the shell script and add to the ansible script.

Here are the dependencies we need for local installation on Ubuntu 16.04:

sudo apt-get install software-properties-common && sudo apt-add-repository ppa:ansible/ansible
sudo apt-get update && sudo apt-get install ansible

@computerality opened a pull request (#47) where some of these issues were discussed.

Sidenote: we may want to use the shellcheck linter to polish up the initial script and find and fix any other compatibility issues.

auditd is the best security feature that no one uses. As an optional feature, we should have Algo configured to log security-critical information and email it out of the VM on a regular basis. The role should use go-audit to get its job done.

There's a lot of sample auditd configuration from CI Security that we copied over to this repo. We should verify that these rules are appropriate:

https://github.com/trailofbits/algo/blob/master/templates/audit.rules.j2
https://github.com/trailofbits/algo/blob/master/templates/auditd.conf.j2
https://github.com/trailofbits/algo/blob/master/templates/CIS.conf.j2
https://github.com/trailofbits/algo/blob/master/security.yml#L44-L52

Here's a short guide for installing and configuring go-audit:
https://summitroute.com/blog/2016/12/25/Catching_attackers_with_go-audit_and_a_logging_pipeline/

It would be nicer to have an easily-typeable but randomly generated password used for the client cert instead of the currently hardcoded password of "vpn"

Since many users will use the VPN on their mobile phone when they travel, we want to ensure they use less data. One way to do that is by blocking ads. Another way to do that is by compressing the remaining content with mod_pagespeed or a similar set of rules.

This would include strongswan installation, deployment of keys and configurations generated by the server deployment, as well as optional security roles to be applied to the client.

https://github.com/oguya/cis-ubuntu-14-ansible
https://github.com/dev-sec/ansible-os-hardening
http://www.codelitt.com/blog/my-first-10-minutes-on-a-server-primer-for-securing-ubuntu/

Emphasis on "reasonable." We should try to do a few more secure defaults without making future system administration a pain or requiring the user setup other systems for logging and whatnot.

https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

There are decent docs available for Windows 7 but it's hard to find if anything changed in Windows 10. It looks like some of these might work but more testing is required:

Encryption: aes128
Integrity: sha1
DH Group: modp1024

We should do an experiment to see how much of an impact the dns ad-blocking and proxies have.

Visit the Alexa top 100 and record the size of the data transfer and speed:

1. Only the VPN
2. VPN + PageSpeed
3. VPN + DNS ad-blocking
4. VPN + Proxy ad-blocking
5. VPN + DNS and Proxy ad-blocking + PageSpeed

Though the install script doesn't specifically say that "~/.ssh/id_rsa.pub" will be used as a default, many (including me) may assume it is and simply hit enter during installation. Doing so generates an error: the file_name '/Users//Temp/algo/roles/cloud-ec2/tasks' does not exist, or is not readable."

There is no file by that name, but there is a folder, which adds to the confusion. Further research proved that the problem was assuming the default during installation...leaving the path for the SSH public key blank causes this error.

Suggest making it clear in the installation that there's no default, or else making the path displayed in the prompt an actual default value. Better still, have the ansible script better check for the path and give a more accurate error response.

A friendly wrapper around deploy.yml for deploying to different providers (EC2, DigitalOcean, etc) should be created.

Currently provider selection is done via passing a variable at the command line.
Ex:
ansible-playbook deploy.yml -e "provider=ec2"

While I fully support implementing all options configurable at the command line through variables for scripting purposes, we need a UI for this.

I tried to enter a p12 password like There's No Hamburger! but it results in a crash:

$ ./algo 
-n 
  What provider would you like to use?
    1. DigitalOcean
    2. Amazon EC2
    3. Google Compute Engine
    4. Remote installation (install to existing Ubuntu server)

Enter the number of your desired provider  
: 
1
-n 
Enter the password for p12 certificates (default: vpn):
: 
ERROR! the playbook: No could not be found

I'm running algo from Mac OS X.

Particularly interested in FreeBSD, HardenedBSD, and OpenBSD.

The readme says

Does not install Tor, OpenVPN, or other insecure servers

Implying OpenVPN is insecure.

However the FAQ only explains why you are not using Tor, Racoon, LibreSwan, or OpenSwan.

I'm not sure the best way to do this, but the intention is to strip advertisements and compress what remains with mod_pagespeed or similar. This likely means that either Apache or Nginx are preferred.

I'm not sure if this should be transparent or not. Maybe we can start off by making it require configuration by the user to turn on the HTTP proxy, and then investigate ways to make it transparent later.

Though I'd installed boto as required, I still got errors on OS X El Capitan with the system not finding boto. Turns out there's a known issue with ansible: ansible/ansible#15019

As suggested, added "ansible_python_interpreter=python" to the "localhost" line in inventory, and it worked fine.

Suggestion: consider adding that setting to the default inventory file, or adding to the README as a possible item needing attention.

This issue was automatically created by Allstar and refers to trailofbits/algo.

Security Policy Violation
PR Approvals not configured for branch master

⚠️ There is an updated version of this policy result! Click here to see the latest update

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

https://github.com/projectatomic/bubblewrap

It looks like Google Chromebooks only support L2TP, oddly:
https://support.google.com/chromebook/answer/1282338?hl=en

However, the Cisco AnyConnect client is available for Chromebooks and it supports IKEv2. It says that it can only be used with Cisco ASA devices but somehow I doubt that is an enforced technical control.
https://chrome.google.com/webstore/detail/cisco-anyconnect/jacdijibdjifphcecdielmekkmfdpgee?hl=en-US

Does anyone have a Chromebook that they can test on?

Most people will use this script to setup a VPN when they travel. When they return home they might stop using the VPN and forget that the VM still exists. This will cost them money. Let's have the VM self-destruct after a given time period by default. 1 month sounds like a good timeframe.

This has security benefits as well, since an attacker would need to setup infrastructure, services, maybe get a warrant, etc to intercept traffic to/from your VPN server. Routinely rotating the infrastructure makes it much harder to "get a fix" on you.

Here's a great implementation of this idea:

• https://github.com/richo/ephemera/blob/master/main.go#L145-L153

We stole a config for this service from the CIS Ubuntu security guide. We should take a closer look at it and see if it's what we really need.

Which one of these is "right"?

• iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o eth0 -j MASQUERADE
• iptables -A POSTROUTING -s 10.0.0.0/24 -m policy --dir out --pol ipsec -j ACCEPT
• iptables -t nat -A POSTROUTING -o eth0 ! -p esp -j SNAT --to-source [server IP]

We should update the README.md with some basic instructions that describe how to use these scripts.

I discovered ssh_scan and the Mozilla OpenSSH Security Guidelines tonight, and discovered a few enhancements we can make to the sshd_config in the process.

HostKeys are apparently an ordered list and OpenSSH still includes RSA and DSA keys by default. We can remove both of those and leave only the ED25519 and ECDSA keys.

# Supported HostKey algorithms by order of preference.
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

There is a HostKeyAlgorithms parameter in sshd_config but I haven't gone through it in enough detail to pick a list of allowed algorithms yet. I think that simply limiting the host key choices to only the above should do what we want for now.

There is an AuthenticationMethods option in newer version of OpenSSH intended to rollup the list of allowed auth methods into a single place. This should be set to pubkey only:

# Password based logins are disabled - only public key based logins are allowed.
AuthenticationMethods publickey

Astonishingly, OpenSSH does not use seccomp out of the box. You have to configure it by hand.

# Use kernel sandbox mechanisms where possible in unprivilegied processes
# Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.
UsePrivilegeSeparation sandbox

None of these make algo radically safer, but they are nice to have.

This is such an enormous pain in the ass, but to ensure that clients don't leak IPv6 requests we should configure this too. At least for Digital Ocean, this requires manual setup on their end to enable IPv6 for the VM.

OpenDNS and Google DNS both have resolvers we can use.

There's something about proxying NDP requests that we need to figure out too, but I'm not sure what that is right now.

I think it's even possible that a client with a configured IPv6 address could leak requests outside the VPN if IPv6 is not supported by it...

https://cloudplatform.googleblog.com/2016/08/how-Google-protects-your-data-Customer-Supplied-Encryption-Keys-for-Compute-Engine-goes-GA.html

Please use some not so regular IP addresses for rightsubnet and rightdns. Those IP addresses have higher chance of clashing with existing subsets which already exist on user's device. Picking some uncommon subnets (like 10.231.87.0/24) from higher ranges of 10.0.0.0/8 is preferred.