strongSwan IPsec Primer

Transcription

strongSwan/IPsec Primer
on Ubuntu
Presentation by Jonathan Davies <[email protected]>
Canonical Technical Services (CTS)
Cloud Development and Operations (CDO)
Canonical Ltd. :: www.canonical.com :: 12/11/2014
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
http://creativecommons.org/licenses/by-sa/3.0/ or send a letter to Creative
Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA.
2 strongSwan/IPsec :: 12/11/14
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.
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.
Document History
Version
Description
v20140618
Initial release.
v20141030
Various improvements after trial-run.
v20141031
Changes post-review feedback.
v20141112
More minor tweaks.
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.
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.
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.
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.
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.
strongSwan The Project
The strongSwan project was born in 2004.
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.
strongSwan Support Status and Testing
strongSwan is in the Ubuntu 'main' repository as of 14.04 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:
●
http://www.strongswan.org/uml/testresults/
In addition to providing a test scenarios, they also provide a brilliant configuration
example resource.
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 4500.
The test of securing communications between two cloud instances as a host-to-host
VPN will be left as an exercise to the reader.
strongSwan Installation
Installing strongSwan on Ubuntu:
Note: Please do this on a 14.04 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.
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.
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.
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
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: “172.16.254.1”.
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.
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
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 \
“172.16.254.1” --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
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
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/
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.
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
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=172.16.254.1
leftcert=gwCert.der
leftid="C=UK, O=Example Ltd., CN=vpn-gw.example.com"
leftfirewall=yes
leftsubnet=172.16.254.0/24
right=%any
rightsourceip=10.0.1.0/24,fec3::/120
auto=add
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 ipsec statusall
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=172.16.254.1
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.
strongSwan Gateway Server Configuration Details (II)
conn rw-vpn
…
leftfirewall=yes
leftsubnet=172.16.254.0/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.
strongSwan Gateway Server Configuration Details (III)
And then we have the 'right' statements for the 'remotes':
right=%any
rightsourceip=10.0.1.0/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 10.0.1.0/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.
strongSwan Gateway Server Configuration Details (IV)
Assuming all went well, we should see something similar to:
...
Virtual IP pools (size/online/offline):
10.0.1.0/24: 254/0/0
fec3::/120: 254/0/0
Listening IP addresses:
172.16.254.1
Connections:
rw-vpn: 172.16.254.1...%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: 172.16.254.0/24 === dynamic TUNNEL
Security Associations (0 up, 0 connecting):
none
The server is now: done and configured.
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=172.16.254.1
rightid="C=UK, O=Example Ltd., CN=vpn-gw.example.com"
rightsubnet=0.0.0.0/0
auto=start
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 ipsec statusall
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
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.
strongSwan Client Configuration Details (II)
Client remotes feature:
right=172.16.254.1
rightsubnet=0.0.0.0/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.
strongSwan Client Configuration Details (III)
Going quickly back to our 'rightid' option:
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.
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, 172.16.10.5[C=UK, O=Example Ltd., CN=client]...172.16.254.1[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}: 10.0.1.1/32 fec1::1/128 === 172.16.254.0/24
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 10.0.1.0/24 -o eth0 -m policy \
--dir out --pol ipsec -j ACCEPT
$ sudo iptables -t nat -A POSTROUTING -s 10.0.1.0/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.
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 172.16.254.1 -j ACCEPT
$ sudo iptables -A OUTPUT -p udp -d 172.16.254.1 --dport 500 -j ACCEPT
$ sudo iptables -A OUTPUT -p udp -d 172.16.254.1 --dport 4500 -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.
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.
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.
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).
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 3706.
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.
strongSwan MOBIKE
strongSwan has full support for the MOBIKE IKEv2 extension as defined in RFC 4555.
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.
strongSwan Configuration :: Compression
strongSwan has full support for the IP Payload Compression Protocol (IPComp) as
defined in RFC 3173.
This can be configured, by adding to the 'conn' entries of both peers's ipsec.conf file:
compress=yes
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 140-2 (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.
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 140-2
(section 4.9.1 again).
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'.
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).
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
}
}
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
…
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).
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 SCR301 00 00
And the ID of the certificate:
$ pkcs15-tool --list-certificates
As shown:
Using reader with a card: Feitian SCR301 00 00
X.509 Certificate [VPN Certificate]
…
ID
: 200dbfe081127b4a50ca0a37e69f19821e2dd9f7
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.
strongSwan Configuration – Smartcards [PKCS#11] (V)
We can now restart the daemon, enter our card PIN and establish the connection as
follows:
$ sudo ipsec rereadsecrets
$ sudo ipsec stroke up rw-gw.vpn
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.
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.
Fin
Merci beaucoup
Jonathan Davies <[email protected]>
Canonical Ltd. :: www.canonical.com

strongSwan IPsec Primer

Transcription

Similar documents

Strategies for Infusing Global Concepts and Content into the K

Certificate of Registration Evans Chemetics LP

Calbag Portland

ISO 9001

Certificate of Registration Glasseal Products Inc.

ISO 14001 - Renosol Corporation

Certificate of Registration Cosmotronic Inc.

Certificate of Registration Lyn

Secure Connect Columbitech Mobile VPN

Certificate of Registration Crissair, Inc.