strongswan/ipsec Primer on Ubuntu

Transcription

1 strongswan/ipsec Primer on Ubuntu Presentation by Jonathan Davies Canonical Technical Services (CTS) Cloud Development and Operations (CDO) Canonical Ltd. :: :: 12/11/2014

2 License This presentation is licensed: Copyright 2014 Canonical Ltd. This work is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License. To view a copy of this license, visit or send a letter to Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. 2 strongswan/ipsec :: 12/11/14

3 Introduction This presentation is intended to be an introduction and overview on IPsec essentials using the excellent tools provided by the strongswan project. Readers are expected to have basic knowledge about the following: Linux system and networking fundamentals. Basic virtual machine experience (including how to spin up a cloud instance). Certificate Authority/PKI fundamentals. How iptables works. However, this document will go step-by-step on how to go about setting up the above. 3 strongswan/ipsec :: 12/11/14

4 Document Formatting, Assumptions and Resources This document has: Text is either white/grey/aubergine. Links are represented with orange text. Terminal commands are represented with grey boxed areas (no output is shown): $ sudo apt-get moo This document assumes that the user is able to install a virtual machine as an IPsec client. IP addresses will be used as examples adjust to your environment as necessary. This document is provided as-is without warranty. Canonical welcomes feedback and contributions. 4 strongswan/ipsec :: 12/11/14

5 Document History Version v v v v Description Initial release. Various improvements after trial-run. Changes post-review feedback. More minor tweaks. 5 strongswan/ipsec :: 12/11/14

6 IPsec Overview As stated on the relevant Wikipedia article: IPsec stands for Internet Protocol Security. It provides a protocol suite for: Authentication assuring that data comes from mutually trusted hosts. Integrity checksum verification to prevent tampering. Confidentiality the use of encryption to protect communications, the keys of which are regularly renegotiated, providing perfect forward secrecy. IPsec operates on the IP layer. It can provide security for all data on a data flow by securing the connection between: Host-to-host two hosts on the same network. Net-to-net across the Internet, two network routers. Host-to-net across the Internet, from a 'roadwarrior' to a remote network. 6 strongswan/ipsec :: 12/11/14

7 IPsec Overview (II) There are roughly two parts to an IPsec implementation: The Kernel the kernel takes care of everything once the encryption or signing keys are known. Userspace tools these negotiate beforehand to set the keys up and give them to the kernel part via an IPsec-specific kernel API. The strongswan project is one implementation of this part. A list of necessary kernel modules for IPsec may be found here for the curious. 7 strongswan/ipsec :: 12/11/14

8 IPsec Overview (III) IPsec is of importance as being a VPN service, it provides data-in-transit protection of data and information and assists with implementing both a data guard and a layer for defense in depth of said digital assets. For instance, as well as authenticating every packet between mutually trusted peers, all traffic destined for a peer or its subnet is encrypted, over the potentially hostile and untrusted Internet/public networks. Because of this information such as the fact that, 1) a VPN client is talking to an IRC/mail/web server on a corporate network, 2) two PostgreSQL servers are replicating database information, is also obfuscated. Instead of seeing normal IP traffic to well known ports (eg. 80/993/5432/6667) a network administrator or attacker would only see an encrypted packet stream to the VPN gateway server/between peers. 8 strongswan/ipsec :: 12/11/14

9 VPN Overview There are essentially two open-source Virtual Private Network (VPN) families of solutions: IPsec which these slides will go into detail in, in the form of the strongswan project. SSL VPN such as OpenVPN and OpenConnect. Other solutions that exist include PPTP and L2TP. 9 strongswan/ipsec :: 12/11/14

10 strongswan Overview As seen on the Introduction to strongswan page. strongswan is a complete IPsec solution providing encryption and authentication to servers and clients/peers. It can be used to secure communications with remote networks, so that connecting remotely is the same as connecting locally. strongswan in essence is a keyring daemon which uses the Internet Key Exchange (IKE) protocols to establish security associations (SA) between two peers. Actual IPsec traffic is not handled by strongswan but instead by the network and IPsec stack of the operating system kernel. 10 strongswan/ipsec :: 12/11/14

11 strongswan The Project The strongswan project was born in strongswan is based on an earlier IPsec solution, called FreeS/WAN. Since its inception, strongswan is maintained by the members of the Institute for Internet Technologies and Applications at the HSR Hochschule für Technik Rapperswil in Switzerland. Where on Earth is Rapperswil? Fine; here's a map¹: Same country that Toblerone comes from. Now you want to go and eat Toblerone. ¹Taken from Open Source Trend Days 2013 Steinfurt strongswan deck. 11 strongswan/ipsec :: 12/11/14

12 strongswan Support Status and Testing strongswan is in the Ubuntu 'main' repository as of LTS and fully supported by Canonical Ltd. The strongswan project also runs a test environment (based on Ubuntu) which runs a series of test cases on every release to catch regressions, these can be found here: In addition to providing a test scenarios, they also provide a brilliant configuration example resource. 12 strongswan/ipsec :: 12/11/14

13 strongswan Environment Preparation Please set up the following environment: A 14.04/trusty server with a public IP this will serve as our VPN gateway. A virtual machine on your system this will serve as a 'roadwarrior' client which will connect to the gateway above. This should be a KVM machine or similar as it requires its own kernel. Note that the security group that your instance boots into must allow UDP connections to ports 500 and The test of securing communications between two cloud instances as a host-to-host VPN will be left as an exercise to the reader. 13 strongswan/ipsec :: 12/11/14

14 strongswan Installation Installing strongswan on Ubuntu: Note: Please do this on a LTS/trusty (or later) system which has strongswan v5. Any older release contains an ancient version of strongswan (v4). This is as easy as: $ sudo apt-get install -y strongswan Take note of the wide range of suggested plug-ins that are available. We'll look into some of those later. 14 strongswan/ipsec :: 12/11/14

15 strongswan Components As stated earlier strongswan is mainly a keyring daemon. This daemon is known as 'charon' within strongswan. To interact with charon we use a tool called 'stroke'. The above are the names of the IKEv2 version of the tooling. The earlier IKEv1 version of the tools were code-named: 'pluto' and 'whack' respectively. 15 strongswan/ipsec :: 12/11/14

16 strongswan Configuration Files The primary configuration files for IPsec are: /etc/ipsec.conf where we configure server/client, IP/domains to connect to, and which certificates to use. /etc/ipsec.d/ where certificates and private keys for the daemon are stored. /etc/ipsec.secrets where we specify which private keys a system should use. /etc/strongswan.conf configuration file which includes the configuration files in the.d directory below. /etc/strongswan.d/.d-style configuration directory for daemon and plug-in settings. 16 strongswan/ipsec :: 12/11/14

17 strongswan PKI Management We will now set up the Public Key Infrastructure (PKI) for our VPN service. Note that this does not have to be managed on the Internet-facing VPN concentrator/gateway. strongswan provides a simple to use tool for these options: $ pki --help 17 strongswan/ipsec :: 12/11/14

18 strongswan PKI Assumptions For those unfamiliar with PKI; this document will proceed with the following PKI settings for the sake of clarity: Country (C) set to United Kingdom (UK). Organisation (O) set to Example Ltd.. CA's Common Name (CN) set to Test VPN. VPN server's DNS and certificate (CN) set to: vpn-gw.example.com. The gateway server's IP address will be: strongswan, similar to HTTPS verification in a web browser, does do hostname checks to verify it is connecting to the right server. It can also be set to connect directly to an IP address (should DNS servers not be trusted). Also note that the above are examples, feel free to adapt them to your environment. 18 strongswan/ipsec :: 12/11/14

19 strongswan PKI Management :: Certificate Authority As with any PKI infrastructure: we require a Certificate Authority (CA). Let's generate an elliptic-curve based private key for our CA: $ pki --gen --type ecdsa > cakey.der Replace --type with 'rsa' if preferred and use the --size option for your paranoia's taste. Refer to --man pki --gen for other options (such as '--outform'). Now let us generate the root certificate for the certificate authority: $ pki --self --type ecdsa --in cakey.der \ --dn "C=UK, O=Example Ltd., CN=Test VPN" --ca > cacert.der View the details of the result: $ pki --print --in cacert.der 19 strongswan/ipsec :: 12/11/14

20 strongswan PKI Management :: Gateway Certificate With our CA in place, we can generate the certificate for our gateway (aka 'VPN concentrator') certificate and then our endpoints. Similar to the CA, we generate a key and certificate but issue the certificate using the CA cert. This can be done with: $ pki --gen --type ecdsa > gwkey.der $ pki --pub --type ecdsa --in gwkey.der pki --issue --cacert cacert.der \ --flag serverauth --flag ikeintermediate --cakey cakey.der --san \ dn "C=UK, O=Example Ltd., CN=vpn-gw.example.com" > gwcert.der Using the --san option (SubjectAltName), one can specify other alternative names for the certificate hostname(s) (see PKI Assumptions notes). We can verify the certificate was correctly issued with: $ pki --verify --cacert cacert.der --in gwcert.der pki --verify --cacert cacert.der --in gwcert.der 20 strongswan/ipsec :: 12/11/14

21 strongswan PKI Management :: Endpoint Certificates Same process for the gateway can be done for the endpoint certificates: $ pki --gen --type ecdsa > clientkey.der $ pki --pub --type ecdsa --in clientkey.der pki --issue --cacert cacert.der \ --flag clientauth --cakey cakey.der \ --dn "C=UK, O=Example Ltd., CN=client" > clientcert.der 21 strongswan/ipsec :: 12/11/14

22 strongswan PKI Management :: File Locations When we install strongswan, the package sets up a series of directories under /etc/ipsec.d/ - we are interested in: cacerts where our VPN's CA certificate will be placed. certs gateway/endpoint certificates (as necessary). private keys for gateway OR sole client endpoint key. We can now move the necessary files into place for every host, on the gateway for example: $ sudo cp -v cacert.der /etc/ipsec.d/cacerts/ $ sudo mv -v gwcert.der /etc/ipsec.d/certs/ $ sudo mv -v gwkey.der /etc/ipsec.d/private/ 22 strongswan/ipsec :: 12/11/14

23 strongswan PKI Management :: File Locations (II) Note: Common sense says never copy a client key over to a client system where it doesn't belong. Once you have your endpoint certs in place for all your systems, you can pretty much put the cakey.der on a USB key and place it in a safe¹. ¹Only to have an emergency 3 years later where you need to regenerate your keys and you come back to it and find out that the USB key died in that time. 23 strongswan/ipsec :: 12/11/14

24 strongswan PKI Management :: CA Check With the certs in place, restart strongswan: $ sudo service strongswan restart For now, it'll only pick up the CA certificate until we add configuration for the VPN's certificate and key. We can verify the CA is in place with: $ sudo ipsec listcacerts Once the configuration is in place, the host certificate can be similarly viewed with: $ sudo ipsec listcerts 24 strongswan/ipsec :: 12/11/14

25 strongswan Gateway Server Configuration Let's open up that ipsec.conf file in our favourite text editor. By default, it features a few commented out example connections. For this example, replace it with the below, values are explained later: # /etc/ipsec.conf - strongswan IPsec configuration file config setup conn %default keyexchange=ikev2 conn rw-vpn left= leftcert=gwcert.der leftid="c=uk, O=Example Ltd., CN=vpn-gw.example.com" leftfirewall=yes leftsubnet= /24 right=%any rightsourceip= /24,fec3::/120 auto=add 25 strongswan/ipsec :: 12/11/14

26 strongswan Gateway Server Configuration (II) Additionally, our server needs to know about our keys to actually do crypto. We do this by adding a line to ipsec.secrets as follows: : ECDSA gwkey.der And now restart the daemon to read all our new configuration and check the status of ipsec: $ sudo service strongswan restart $ sudo ipsec statusall 26 strongswan/ipsec :: 12/11/14

27 strongswan Gateway Server Configuration Details So what does this do? Let's go through it line-by-line. %default settings are inherited by all 'conn' section. conn %default keyexchange=ikev2 This tells strongswan to only use the Internet Key Exchange protocol version 2. conn rw-vpn left= leftcert=gwcert.der leftid="c=uk, O=Example Ltd., CN=vpn-gw.example.com" Here we define a connection, named 'rw-vpn' (roadwarrior vpn) and we specify details for the 'left' side of the connection (think: local). We give it an IP to bind on, a certificate to authenticate the server, and an ID to use. 27 strongswan/ipsec :: 12/11/14

28 strongswan Gateway Server Configuration Details (II) conn rw-vpn leftfirewall=yes leftsubnet= /24 leftfirewall is mainly required when the default firewall policy of the INPUT/FORWARD chains are DROP. This option causes a rule to be added to allow traffic to flow. While leftsubnet specifies which subnet will be forwarded to VPN connections. In this case, the global internet. This, however, can be restricted to one or more subnets which the server is linked to instead. The client will always respect what the server sets. 28 strongswan/ipsec :: 12/11/14

29 strongswan Gateway Server Configuration Details (III) And then we have the 'right' statements for the 'remotes': right=%any rightsourceip= /24,fec3::/120 This states that remote connections may come from %any IP address on the Internet. Also, when a roadwarrior connects, they should be assigned a virtual IP on the VPN network from the IPv4 range /24 and the IPv6 range fec3::/120. auto=add Tells strongswan to merely add the configuration details to its knowledge, but not actually initiate a connection. This is the reasonable setting for servers. The certificate and connection settings are complete. More information about 'conn' settings may be found at this page. 29 strongswan/ipsec :: 12/11/14

30 strongswan Gateway Server Configuration Details (IV) Assuming all went well, we should see something similar to:... Virtual IP pools (size/online/offline): /24: 254/0/0 fec3::/120: 254/0/0 Listening IP addresses: Connections: rw-vpn: %any IKEv2 rw-vpn: local: [C=UK, O=Example Ltd., CN=vpn-gw.example.com] uses public key authentication rw-vpn: cert: "C=UK, O=Example Ltd., CN=vpn-gw.example.com" rw-vpn: remote: uses public key authentication rw-vpn: child: /24 === dynamic TUNNEL Security Associations (0 up, 0 connecting): none The server is now: done and configured. 30 strongswan/ipsec :: 12/11/14

31 strongswan Client Configuration On the client, we also configure ipsec.conf file and add: # /etc/ipsec.conf - strongswan IPsec configuration file config setup conn %default keyexchange=ikev2 keyingtries=%forever conn rw-gw.vpn left=%any leftcert=clientcert.der leftid="c=uk, O=Example Ltd., CN=client" leftsourceip=%config4,%config6 leftfirewall=yes right= rightid="c=uk, O=Example Ltd., CN=vpn-gw.example.com" rightsubnet= /0 auto=start 31 strongswan/ipsec :: 12/11/14

32 strongswan Client Configuration (II) We now make the client register its private key in /etc/ipsec.secrets as follows: : ECDSA clientkey.der And now restart the daemon to read all our new config and check the status of ipsec: $ sudo service strongswan restart $ sudo ipsec statusall 32 strongswan/ipsec :: 12/11/14

33 strongswan Client Configuration Details And now the client: conn %default keyexchange=ikev2 keyingtries=%forever Same again; Internet Key Exchange protocol version 2 and additionally telling the strongswan client to continuously attempt to connect to the server. conn rw-vpn.gw left=%any leftcert=clientcert.der leftid="c=uk, O=Example Ltd., CN=client" leftsourceip=%config4,%config6 leftfirewall=yes Connection definition, named 'rw-vpn.gw' (roadwarrior vpn gateway), using %any (the default) IP address available locally on the 'left' side along with a certificate to authenticate the server, the ID to use. The main difference is that we ask the server to provide us with an IPv4 and IPv6 address from its configuration. See the VirtualIP page for more information. 33 strongswan/ipsec :: 12/11/14

34 strongswan Client Configuration Details (II) Client remotes feature: right= rightid="c=uk, O=Example Ltd., CN=vpn-gw.example.com" rightsubnet= /0 'right' is set to your floating IP/the FQDN to connect to (vpn-gw.example.com). And the gateway's ID is set to verify it (this is done with the CA certificate). 'rightsubnet' specifies which IP ranges the client would like to have forwarded to the gateway securely (in this case everything). The client and server, naturally, have to agree on which network traffic will be forwarded. auto=start Tells strongswan to initiate the connection to the server when the configuration is loaded. 34 strongswan/ipsec :: 12/11/14

35 strongswan Client Configuration Details (III) Going quickly back to our 'rightid' option: rightid="c=uk, O=Example Ltd., CN=vpn-gw.example.com" This could instead be specified as, which would use the CN of the certificate: rightid=vpn-gw.example.com The above setting will cause strongswan to do a hostname verification check against what's set in the certificate. 35 strongswan/ipsec :: 12/11/14

36 strongswan Client Configuration Details (IV) And now in our status, we should see an established tunnel and a security association, as seen from the client:... Security Associations (1 up, 0 connecting): rw-gw.vpn[1]: ESTABLISHED 107 seconds ago, [C=UK, O=Example Ltd., CN=client] [C=UK, O=Example Ltd., CN=vpn-gw.example.com] rw-gw.vpn[1]: IKEv2 SPIs: 73fd38253a8340a4_i* b28d9ddf77bced6a_r, public key reauthentication in 2 hours rw-gw.vpn[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 rw-gw.vpn{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: ce50c2de_i cec03d55_o rw-gw.vpn{1}: AES_CBC_128/HMAC_SHA1_96, 370 bytes_i (4 pkts, 9s ago), 265 bytes_o (4 pkts, 9s ago), rekeying in 44 minutes rw-gw.vpn{1}: /32 fec1::1/128 === /24 36 strongswan/ipsec :: 12/11/14

37 strongswan Gateway Firewall Configuration The tunnel is now established, IPsec configuration is now out of the window in terms of being a concern. Normal IP routing and forwarding rules now come into play; on the gateway server, we must configure the firewall to allow routing of packets back to the VPN clients from the outside world (the source IP would be from a private range and thus would never reach the VPN gateway): $ sudo iptables -t nat -A POSTROUTING -s /24 -o eth0 -m policy \ --dir out --pol ipsec -j ACCEPT $ sudo iptables -t nat -A POSTROUTING -s /24 -o eth0 -j MASQUERADE And now the server can be set to act as a router: $ sudo sysctl -w net.ipv4.ip_forward = 1 More information can be found at the ForwardingAndSplitTunneling page. 37 strongswan/ipsec :: 12/11/14

38 strongswan Client Firewall Configuration Client iptables rules for configured network traffic are injected dynamically with the leftfirewall=yes option (applies only if default firewall policy is: DROP). However, client security can be further enhanced by only allowing IPsec-based traffic to go down the wire, as follows. $ sudo iptables -P INPUT DROP $ sudo iptables -P FORWARD DROP $ sudo iptables -P OUTPUT DROP $ sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT $ sudo iptables -A INPUT -i lo -j ACCEPT $ sudo iptables -A OUTPUT -o lo -j ACCEPT $ sudo iptables -A OUTPUT -p esp -d j ACCEPT $ sudo iptables -A OUTPUT -p udp -d dport 500 -j ACCEPT $ sudo iptables -A OUTPUT -p udp -d dport j ACCEPT Note that the above inhibits the use of captive-portals (such as public wifi hotspots), and local network resources such as DNS servers. Everything permitted must reside on the IPsec VPN in this lockdown scenario. 38 strongswan/ipsec :: 12/11/14

39 strongswan Peer Cipher Configuration Peers can specify other ciphers other than the default options by using the 'ike' and 'esp' options in ipsec.conf. An example alternative configuration from the default would be the following: ike=aes128gcm128-prfsha256-ecp256! esp=aes128gcm128-ecp256! The above uses AES128-GCM with 128-bit keys and NIST Elliptic Curve Groups with 256 bits modulus for encryption and integrity. Additionally SHA2 256 is used for a psuedo-random function. For more, see the IKEv2CipherSuites and CipherSuiteExamples pages. 39 strongswan/ipsec :: 12/11/14

40 strongswan Peer DNS Configuration Clients can have DNS configuration set over the VPN via the configuration payload (CP). This can be done by setting the 'dns1' and 'dns2' settings in /etc/strongswan.d/charon.conf on the VPN gateway server. Additionally, a DNS server can also be set with the 'rightdns' option in ipsec.conf. Ubuntu via resolvconf has full support for the dynamic setting of DNS servers via this method. Note that these DNS servers can be serving private DNS names to IPs on gateway's left subnet, providing for a private secure intranet, which is not visible from the Internet. Also worth noting is the fact that glibc has a hard-limit of 3 DNS resolvers. 40 strongswan/ipsec :: 12/11/14

41 strongswan Peer VPN Reconnect Configuration Peers can be instructed to automatically reconnect to another peer by setting under a 'conn' entry in /etc/ipsec.conf: closeaction=restart The above sets security associations to be restarted when they are closed by a remote peer. The option can be problematic if reauth=yes (the default) is used as this could cause loops (depending on which peer starts the re-authentication). 41 strongswan/ipsec :: 12/11/14

42 strongswan DPD Configuration VPN peers can also be set to periodically query each other for liveliness with what is known as the Dead Peer Detection (DPD) protocol as defined in RFC This is set in a conn section in ipsec.conf with: dpdaction=restart The daemon will regularly check its peers by sending empty INFORMATIONAL Messages. Note that if keyingtries is not changed the daemon will only try three times to reestablish the connection. 42 strongswan/ipsec :: 12/11/14

43 strongswan MOBIKE strongswan has full support for the MOBIKE IKEv2 extension as defined in RFC This enables strongswan to roam to an other interface/address or update its routing if a better path to a peer is found. More information on the MOBIKE page. 43 strongswan/ipsec :: 12/11/14

44 strongswan Configuration :: Compression strongswan has full support for the IP Payload Compression Protocol (IPComp) as defined in RFC This can be configured, by adding to the 'conn' entries of both peers's ipsec.conf file: compress=yes 44 strongswan/ipsec :: 12/11/14

45 strongswan Configuration :: Integrity Checks See also the IntegrityTest page on the strongswan wiki. strongswan may be configured to run an integrity check of the daemon, libraries and plug-ins. This is to provide the system administrator the assurance that these binaries match what left the package build farm. This can be enabled by changing the integrity_test setting in the charon section of the /etc/strongswan.d/charon.conf file to 'yes'. Upon restarting the daemon, a checksum check can be observed in /var/log/syslog. This implements the Power-Up Test requirement of FIPS (section 4.9.1). Note that this check performs a simple 32-bit hash check and should complement but not replace a strong system integrity checking application. 45 strongswan/ipsec :: 12/11/14

46 strongswan Configuration :: Cipher Checks See also the CryptoTest page on the strongswan wiki. Additionally, strongswan can be configured to perform checks on its cipher families on: Daemon start-up. Connection instantiation (guarantees implementation is behaving correctly correctly over a longer period of time). This implements the Cryptographic algorithm test requirement of FIPS (section again). 46 strongswan/ipsec :: 12/11/14

47 strongswan Configuration :: Cipher Checks (II) These cipher checks are configured by setting in /etc/strongswan.d/charon.conf: on_add. on_create. required....to 'yes'. 47 strongswan/ipsec :: 12/11/14

48 strongswan Smartcards :: Hardware The next section touches on smartcards and their usage with strongswan for twofactor authentication. This capability was tested with: A Feitian SCR301 card reader. A Feitian PKI as a smartcard (allows up to 2048-bit RSA keys). However, as long as the card is usable with OpenSC in terms of reading and writing certificates and keys; anything should be able to interface with strongswan. Additional information can be found on the Smartcards page on the strongswan wiki. This page also touches on how to initialize a card, and import certificates and keys into the card. Note that this guide has used ECDSA keys for all other sections which will require a ECC-capable smartcard (such as for instance: SmartCard HSM). 48 strongswan/ipsec :: 12/11/14

49 strongswan Configuration Smartcards [PKCS#11] strongswan may be configured to use smartcards PKCS#11 which in Ubuntu, is implemented with OpenSC. On Ubuntu, the strongswan-plugin-pkcs11 must first be installed on the client: $ sudo apt-get install -y strongswan-plugin-pkcs11 opensc The plugin must now be configured to use the shared library as follows in the /etc/strongswan.d/charon/pkcs11.conf file: modules { opensc { path = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so } } 49 strongswan/ipsec :: 12/11/14

50 strongswan Configuration Smartcards [PKCS#11] (II) strongswan detects which certificate to read off the card by iterating through the card's certificates and looking for a match to what's set in ipsec.conf's leftid. Going back to the example configuration on the Client Configuration page, this involves just setting: conn rw-gw.vpn left=%any leftid="c=uk, O=Example Ltd., CN=client" At this point, it is also desirable to set the auto= option to 'add' (as we have to enter a PIN before the private key can be read from the card). 50 strongswan/ipsec :: 12/11/14

51 strongswan Configuration Smartcards [PKCS#11] (III) For the VPN private key, we first need to identify which slot our card is in: $ pkcs11-tool --module opensc-pkcs11.so --list-slots Which shows: : Available PIN %smartcard1:800dafc071152b4a59ca0a34e89f19871e2dd9f7 slots: Slot 1 (0x1): Feitian SCR And the ID of the certificate: $ pkcs15-tool --list-certificates As shown: Using reader with a card: Feitian SCR X.509 Certificate [VPN Certificate] ID : 200dbfe081127b4a50ca0a37e69f19821e2dd9f7 51 strongswan/ipsec :: 12/11/14

52 strongswan Configuration Smartcards [PKCS#11] (IV) With the slot and certificate ID, we are ready to compose our ipsec.secrets file: : PIN %smartcard1:200dbfe081127b4a50ca0a37e69f19821e2dd9f7 %prompt Alternatively, instead of '%prompt' we can specify the PIN of the card. While this file is owned by root, this may not be a desirable configuration. The 'leftcert' option in ipsec.conf can be used with '%smartcard...' to select a specific certificate as per the above syntax. 52 strongswan/ipsec :: 12/11/14

53 strongswan Configuration Smartcards [PKCS#11] (V) We can now restart the daemon, enter our card PIN and establish the connection as follows: $ sudo service strongswan restart $ sudo ipsec rereadsecrets $ sudo ipsec stroke up rw-gw.vpn 53 strongswan/ipsec :: 12/11/14

54 strongswan Daemon Security :: AppArmor The Ubuntu package for strongswan ships with various AppArmor profiles which are enabled by default. One of these profiles sandboxes the Internet-facing part of strongswan, charon, so that it is only able to read and write to files which it is explicitly authorised to, even though by default it runs as root. These AppArmor profiles may be found at the usual location at: /etc/apparmor.d/usr.lib.ipsec.charon /etc/apparmor.d/usr.lib.ipsec.* For more information about AppArmor, please see its Wikipedia page. 54 strongswan/ipsec :: 12/11/14

55 strongswan Practical Applications Practical examples of scenarios in which strongswan could be used include: Government/enterprise environments where clients are locked down to a VPN server. Bank ATM network sending data back to a centralized control network. Securing connections from a client to a private cloud network. Securing connections between two private cloud networks. 55 strongswan/ipsec :: 12/11/14

56 Fin Merci beaucoup Jonathan Davies Canonical Ltd. ::