Grumpy Networkers Journal Documentation

Transcription

1 Grumpy Networkers Journal Documentation Release Head In The Cloud Jun 22, 2017

2

3 Contents: 1 Networking Virtual Private Networks Network Protocols Security Common Network Attacks Securing the Switch Infrastructure Segregating Networks using Firewalls Cryptography Overview Authentication Services Cloud Services Cloud Deployment Models Cloud Service Models Documentation Sphinx Study Notes Cisco CCNP - Implementing Cisco Secure Mobility Solutions ( SIMOS) Cisco CCNP - Implementing Cisco Edge Network Security Solutions ( SENSS) Vendor Implementations Cisco Implementations To Do Glossary of Terms External References PPTP Sphinx Indices and tables 123 Bibliography 125 i

4 ii

5 Warning: You agree to use anything included in this journal at your own risk, I make no guarantees that anything included will work in your environment or that it is even accurate. By making this journal public I hope that it is of use to fellow network/security engineers either in teaching them new things or troubleshooting that tricky problem. It is highly recommended that before trying any of the listed configurations that you do you own additional research to make sure it is compatible with your equipment and/or infrastructure. Contents: 1

6 2 Contents:

7 CHAPTER 1 Networking dsfsdfsdfsdfsdfd Virtual Private Networks IPSEC VPNs IKE Version 2 Overview IKE Version 2 or simple IKEv2 for short was published in RFC4306 but has since been updated by a number of other RFCs, the latest being RFC It offers a number of improvements over the previous incarnation where weaknesses have been identified. Ihis is mostly a benefit it must be understand that the two versions whilst still similar are incompatible with each other and therefore both peers must support the new version of the protocol. The establishment of an IKEv2 VPN starts with an IKE_SA_INIT meesage whereby both peers negotiate a set of algorithms and agree on the secret key that is derived from additional key material. Additiona random data is added in the form of a nonce. Once established all furter messages will be encrypted and the integrity validated. The second part of the exchange called an IKE_AUTH is secured using the agreed properties from the first exchange. Each side of the exchange will authenticate each other using an integrity check generated from the secrets associated with their identity. Peers will then exchange algorithms that will be used to protect one or more IPSEC SAs using either ESP or AH that is then used to secure the actual user traffic. Each time an additional IPSec is required (Such as adding a new subnet to be encypted), an additional IKEv2 exchange will occur called a CREATE_CHILD_SA. In the case of IKEv22 these exchange are not referred to as Phase 2 SAs but instead called a Child SA. 3

8 Nonce In order to make the output of the cryptographic function less predicatable. A certain amount of randomness is added. This is the purpose of the nonce and is a randomly generated value that is used as input to the data when authenticating peers. The nonce is sent by the initiator. The nonce must be a minimum of 128 bits an up to 2048 bits in size. In practice the nonce must be at least half the size of the output for the PRF function that is negotiated. Denial of Service Protection In order to offer more protection against Denial of Service IKEv2 provides defences in the form of cookies. These cookies are designed to defend against blind spoofing attacks as the initating party must be able to reply to the cookie request which is a lot less computationally expensive that a real IKEv2 exchange. In the event an IP address is spoofed, no reply will be forthcoming that the receiving party will not have wasted a lot resource establishing and storing the intial state for a peer that doesnt exist. The point at which this protection is enabled is configurable when a certain number of half connections are seen. This Denial of service protection only helps against attacks that are using faked IP addressing, in the situation where the real host (such as one involved in a botnet) is making the request and is able to reply resources would still be consumed. In the case of certain vendors, this protection is not enabled by default (such as Cisco). When enabled the initial IKE_SA_INIT is increased from a two way exchange to a four way exchange as the cookie needs to be send and received before the IKE responder will sent cryptographic material. Certificate Request In IKEv1 when certificate authentication was used the subject name of the CA was included. This introducted the risk that it could be duplicated. In IKEv2 this has been removed and now the responder can request that the initiator use a certifiate issued from a preferred cerificate authority by sending the SHA-1 hash of the public key of any trusted CA. The peer receiving the request can select a CA from one of those in the request. Out-of-Band Certificate Lookup Instead of receiving the request directly in the IKE exchange a peer can notify of it s ability to retrieve a certificate via HTTP instead. The sending peer will then provide the 160-bit SHA-1 hash of the certifiate along with the URL where it can be be downloaded from. This is useful in situations where fragmentation may occur due to the size of the certificates or certificate chain. It should be noted that this method of authentication is not widely supported by all devices/vendors. Extensible Authentication Protocol (EAP) IKEv2 includes support for EAP as a valid method of authenticating an initiator. The responder must use a form of certificate (either RSA or ECDA) as it s means of authentication when a reply is sent to the initiator. In this instance the initiator will repond first with it s identity. 4 Chapter 1. Networking

9 Initial Contact In the event of a VPN peer crashing or other issue that causes it to loose the current cryptographic material IKEv2 includes a mechanism in which to detect if an existing SA is in place and to tear it down so a new session can be established. This is based on the premise that there is no point waiting resources trying to send encrypted packets to an endpoint that has no means to decrypted them. It is better to simply tear it down and start from scratch by agreeing new keying material. Dead Peer Detection IKEv1 included a means of sending keepalives to ensure that its peer were active and should be able to receive data. This however was wasteful on resources especially on a busy hub. An improvement was added to IKEv1 was an option called Dead Peer Detection. Whilst similar to keepalives, it is far more scaleable as it only sent keepalives when no data was being seen from that remote peer. As long as data was being seen or no data needed to be sent, the DPD mechanism would do nothing. One issue does exist however, because DPD will only sent a request when traffic needs to be sent over the VPN it may not notice the failed peer straight away. By using routing protocols over the tunnel however, this should not be an issue as they will notice the failure more quickly and where redundant links exist will reconverge as necessary. It is recommended that DPD be enabled so that in the event of failed peers the now unnecessary security assoications can be torn down. On the hub however if a large number of VPN peers fail this may place a lot of additional burden on this central device. Whilst DPD should be enabled on all spoke devices, care should be taken not to set the DPD timeout values too aggressive so that it doesn t support from a Denial Of Service simply due to having to process to many DPD request/replies. NAT-T NAT-T offers a mechanism by which IPSec traffic can be sent through a NAT device. It was an optional features in IKEv1 but is mandatory in IKEv2. NAT-T works by encapsulating the ESP packets within a UDP packet (usually using UDP 4500) so that the NAT device can individually track the connections coming through it based on the source/destination port numbers. Prior to NAT-T it was necessary for devies to support IPSec Passthrough whereby the needed to keep track of the SPI information in the ESP headers to know what to do and this ofter limited the ability of the feature (for example only one IPSec device at a time). One problem that exists is when an IPSec connection is idle it isn t sending or receiving any data so this would cause the NAT gateway to start the idle timer because according to RFC 3715 NAT entries should have finite lifetime. This is taken care of by sending NAT-T keepalives at certain intervals to avoid the NAT gateway tearing down the sessions. It should be noted that these keepalive packets whilst not carrying any protected data, are not encrypted in any way. A single payload of 0xFF is included in the packet. Note that because of the way in which Authentication Header (AH) validate the packet, it is still not possible to use AH and NAT with IKEv2 just as with IKEv1. NAT detection is included as part of the protocol and when detected the peers will automatically switch to encapsulating the IKE and IPSec sessions within UDP (IP Protocl 17) over port 4500 (unless configured otherwise). IKEv2 and IKEv1 Comparison As previously mentioned although they perform the same function IKEv1 and IKEv2 and not compatible Virtual Private Networks 5

10 Two of the biggest advantages of IKEv2 are its inclusion of Next Generation Encryption (NGE) and anti denial-ofservice capabilities. IKEv2 also includes EAP authenticaton which was not available as part of IKEv1. The overall packet structure of IKEv2 has also been redesigned to be more efficient, needing fewer packets and less bandwidth that IKEv1. The current form of IKEv1 is the combination of numerous RFCs which have resulted in a number of bolt-on features being added to IKEv1. Many of these features are now included in IKEv2 by default and therefore allowed for a cleaner design. IKEv2 no longer provides for Main Mode or Aggressive mode, instead there is a single IKE_SA_INIT as covered above. In IKEv1 the lifetime of the IKE SA was negotiated in the first pair of messages. This resulted in incompatibilities due to mismatched values. For IKEv2 the lifetime is now a locally configured value which is not negotiated between peers. A peer is responsible for deleting or rekying the SA when it s local lifetime expires. Whilst ECDSA authentication was introduced to IKEv1 it was late coming and therefore has seen little adoption. It has however seen wide adoption in IKEv2 and a requirement for implementations to support the Suite B Profile (RFC 6380) IKEv1 has no support for high availability resulting in tricks such as DNS round robin or using a dedicated load balancer. IKEv2 provides for a redirection ability where a client can be told to connect to another VPN gateway. The IKEv2 provides for a wider range of traffic selectors as well as allowing the responder to select a narrower set than the initiator proposed, this can be done per Child SA. The official standard allows for a single IPSec SA to handle both IPv4 and IPv6 traffic however not allow Vendor (including Cisco) provide support for this. NAT has already been covered above, NAT-T and NAT detection were originally not included as part of the IKEv1 standard but they are now as part of IKEv2. IKEv1 did not include any method for pushing configuration to peers (such as IP addressing in the case of a remote access client). IKEv2 has inbuilt support for configuation data exchange via the use of a configuration payload. In IKEv1 when pre-shared keys were used it was not possible to based identity on anything other than the peer IP address. Because IKEv2 does not use the shared secret as part of its initial calcuation other identity details can be used. It is assumed that because the peer was able to perform these calculations that it must have possesion of the private key and therefore its identify can be more trustworthy. Because of the above IKEv1 needed to have a unique IP per pre-shared-key. IKEv2 does away with this limitation. IKEv2 is also considered more reliable as message exchanges are sent in pairs so a response is always expected. In IKEv1 all sets of cryptographic ciphers are transferred in seperate transforms. In IKEv2 all algorithms are sent within a single transform, or two where combined and non-combinded mode ciphers are used. IKEv2 is able to provide combined mode ciphers in which a single algorithm is able to perform both encryption and integrity protection. In IKEv1 it was possible for an IPSec SA to exist without a corresponding IKE SA. This is due to IKEv1 not operating in a noncontinuous channel mode. In IKEv2 this is not possible as for an IPSec SA to exist it must have a matching IKEv2 SA. Introduction It s been mentioned already in the overview of VPN technologies that IPSec is not a single protocol instead a suite of protocols working together to provide the necessary security services. RFC 2401 defines the fundamental components of IPSec to be: 6 Chapter 1. Networking

11 Security Protocols Key Management Algorithms Due to the way in which IPSec works it s not easy to understand one of these components without understanding the offers. Encryption is a fundamental part of various IPSec functions and the relevant terminalogy will be mentioend as necesary. For a more detailed understanding, consult the chapters in this journal on Cryptography These notes were written up as part of my studies for the CCNP SIMOS exam in May 2017 as served as part of my revision. They are not intended to be complete discussion of the entire IPSec Protocol stack. Security Protocols The purpose of IPSec is to provide protection for the data that is being transmitted over the network. Depending on the nature of the traffic a number of services can be offered as covered previously: Access Control Confidentiality Data Integrity Authentication Protection against replay IPsec provides two protocols that offer different levels of protection to the data, these protocols are Encapsulating Security Payload (ESP) and Authentication header (AH). Each of these protocols again can be used along with different encapsulation methods depending on the type of network they are being used on. The methods of encapsulation are called Transport and Tunnel mode and will be covered first. Transport vs Tunnel Mode Transport Mode Transport mode works by inserting the ESP or AH header between the original IP header and the upper layer protocol (e.g. UDP or TCP). The IP header remains the same except for the IP protocol field, the IP header checksum is recalculated. When this mode is used any routing is based on the original destination IP address. Because of this it is most useful when traffic between two hosts needs to be protected but becomes more difficult when moving to a site-to-site deployment. When combined with GRE, transport mode still has it s uses as in this instance the GRE endpoint serves as the host endpoint. Another limitation of transport mode is that it cannot used along NAT translation between two IPSec peers. In the case of AH, this is because NAT changes the source IP address in the IP header therefore it will no longer match the AH header causing the receiving endpoint to drop the packet. For ESP, it is possible that NAT may work but as the higher level protocol is encrypted a NAT device cannot read more specific information (such as port numbers) so is more limited in the type of NAT it can do. Depending on the NAT device in front of the VPN device it may be limited to just one device, more advanced devices may be able to read the ESP information (such as the SA s) and make enough sense out of them to determine the individual connections Virtual Private Networks 7

12 It is also potentially less efficient that tunnel mode due to the encryption engine having to displace (effectively rewriting) the IP header rather than just encrypting the entire packet. The size of the packet will also be increased due to the additional headers which could lead the packet being oversized for the networks supported MTU. This however is not as much as concern as it is for Tunnel mode. Tunnel Mode Tunnel mode works by encrypting the entire original IP packet into another IP datagram and an AH or ESP header is added between the outer and inner headers. In the case of AH, the entire new packet is authenticated (excluding certain mutable fields, such as TTL). This means that it still will not work through a NAT gateway. For ESP, everything except the new IP Header is authenticated and the original packet along with ESP trailer is encrypted. Because the new IP header is not taken account of if the packet is modifed it can pass through NAT without issue (assuming the NAT gateway supports IPSec Passthrough otherwise same limitates as transport mode). The primary benefit however is that routing decisions are now based on the outer IP header meaning it can pass over public networks using globally unique IP addresses, keeping the inner (private) IP addresses completely hidden until the packet reaches the other VPN gateway. The downside to tunnel mode however is that because it includes an additional IP header along with ESP header, trailer this increases the packets size quite substantially which may take it over the allowed MTU of the given network. Encapsulated Security Payload vs Authentication Header IPSec offer two means by which the original packet data can be encapsulated. Sometimes all that is required is to ensure that the data has not been modified other times confidentiality is essential to offer as much protection as possible that the data has not been examined en route to it s destination. Encapsulating Security Payload (ESP) The Encapsulating Security Payload header provides all of the necessary services for a secure VPN as covered under Security Protocols. This implementation is achieved by enclosing the encrypted version of the orignal payload inside of an ESP header and trailer. The ESP header is indicated by setting the upper layer protocol in the IP header to IP Protocol 50. One of the key fields inthe ESP header is the security parameter index (SPI), this along with the destination address and protocol in the IP header identifies the security association to be used to process the packet. The SPI can be used to looking the SA in the security association database (SADB). A sequence number is included in the header by the header and is simply a unique increasing number used to provide replay protection services. It should be noted that the ESP header itself is not encrypted otherwise the remote peer would not be able to identify which connection the packet is associated with. It also explains why for more advanced NAT gateway s it may be possible for ESP traffic to pass through them without issue. Authentication Header (AH) Unlike ESP, Authentication Header doesn t provide confidentiality and replay protection is optional. 8 Chapter 1. Networking

13 AH sets the upper layer protocol in the original IP header to IP Protocol 51. Because AH creates the authentication data based on the entire packet, it s possible some of this may change in transit resulting in the authentication failing. To combat this the following fields are zero d out before the authentication digest is hashed: ToS Flags Fragment Offset TTL Header checksum Key Management And Security Associations Phase 2 Quick Mode IPSEC Packet Processing SPD SADB Key management is the process of generating, distributing and storing of encryption keys. In IPSec the Internet Key Exchange (IKE) protocol is is the default method for secure key negotiation. In order to exchange keys over an insecure transport medium, IKE uses the Diffie-Hellman Key management protocol. Diffie-Hellman Key Exchange The DH Key Exchange depends on the discrete logarithm problem where it assumes that it is computationally infeasable to calculate a shared secret key given two public values. It works by calculating two values a generator (g) and a parameter (p). The two communicating parties (Alice and Bob) calculate a random private value (a and b respectively). A public value is then derived using the previos p and g values Alice will calculate her public value as X = g a mod p Bob will calculate his public value as Y = g b mod p These public values are then exchanged between Alice and Bob. Alice then calculates k ab = (g b ) a mod p Bob calculates k ba = (g a ) b mod p Because k ab = k ba = k they now know the shared secret key k. Security Association A security association (or SA for short) is a basic building block of IPSec. The SA is an entry in th SA Database (SAdB) that contains information about the security that has been negotiated between two parties for IKE or IPSec. There are two types of SA, both of which are established between peers using the IKE protocol: IKE or ISAKMP SA 1.1. Virtual Private Networks 9

14 IPSec SA The IKE SA is used for traffic that controls the VPN tunnel such as when negotiating algorithms to use to encrypt IKE traffic and to authenticate peers. There is only one IKE SA between peers and commonly has less traffic along with a longer lifetime that IPSec SAs. IPSec SAs are used for negotiating the encryption algorithms to apply for IP traffic (the actual user data) between peers. Each IPSec SA is unidirectional so there will always be at least two IPSec SAs (one in each direction). It is also possible to have multiple pairs of SAs as each defines a unique set of IP hosts or IP data traffic (for example one pair per source/destination network specified). The establishment and maintenance of both types of SAs is the major function of the IKE protocol. The definition of how this key exchange and negotiaion is done is divided into IKE (RFC 2409), ISAKMP (RFC 2408), OAKLEY (RFC 2412) as well as the ISAKMP Domain of Intepretation (RFC 2407). Although ISAKMP and IKE are used interchangably they are different. ISAKMP provides the means to authenticate a peer and to exchange information for key exchange. IKE defines how the key exchange is done. IKE operates in two phases in order to establish the SAs for IKE and also IPSec: Phase 1 provides mutual authentication of the VPN peers and establishment of the session key. This creates the ISAKMP SA or IKE SA using DH excahnge, cookies and an ID exchange. Once established all IKE communication between the initiator and responder is protected with both encryption and integrity checks. This then provides a secure channel so that Phase 2 negotiations can be performed safely. Phase 2 provides the negotiation and establishment of IPSec SAs using either the ESP or AH protocols to protect IP data traffic. IKE Phase 1 Operation Phase 1 can be performed in one of two modes, Main or Aggressive. Either way the result is the establishment of an ISAKMP/IKE SA. The IKE SA has a number of mandatory parameters: Encryption Algorithm (e.g. 3DES) Hash/Integrity Algorithm (e.g. SHA1) Authentication Method (e.g. Pre-shared keys) Diffie-Hellman Group (e.g. Group 2) Other parameters are optional, such as SA Lifetime and most devices will have a default value for this if not defined (in terms of seconds or kilobytes) Comparision of Main and Aggressive Mode Main Mode Main mode communicates 6 messages between peers starting with the Initiator. It offers identity protection and flexibility in terms of the parameters and configurations that can be negotiated. The exchange occurs as follows: 1. initiator sends initiator cookie and SA payload which contains the Phase 1 parameters. 2. The responder replies with the selected parameters for each of the proposals along with the SA header response and the ISAKMP Header with a responder cookie 10 Chapter 1. Networking

15 3. The 3rd and 4th messages occur when the keying materials are being exchanged. and a number of different keys are derived used for the late exchanges. 4. The 5th and 6th messages are encrypted using the keys created in the previous steps and authenticated using the hashes derived. The proposals must be selected or denied in their entirety, the responder is not allowed to pick and choose elements from different properties. In addition in Main Mode the ID Payload is encrypted so the responder cannot determine who it is talking to therefore when authenticating using a pre-shared key, the identity can only be determined based on the source IP address. Aggressive Mode Aggressive Mode completes it s exchange using only 3 messages which speeds up the IKE transaction processing. This speed however comes at a cost of some security. The 3 messages are exchanged as follows: #. Initiator sends the ISAKMP header, security association, DH public value, nonce and identification ID. 1. The responder then replies with the choosen transform set for each of the proposals and the DH half key. This message is authenticated but not encrypted. 2. The initiator then replied to the responder with the message authenticated so that the responder can make sure the hashes matches the one calculated. In the past one of the primary uses for Aggressive mode was for remote access IKE clients as the responder would have no prior knowledge of the source IP address of the initiator and pre-shared keys were used for authentication. Because identities are passed in the clear and DH parameters cannot be negotiated, Agressive Mode is deemed less secure. As a hash of shared secret is passed in clear text, if an eavesdropper was able to intercept this an offline brute force attack could be used to obtain the clear-text secret. In modern networks where sites are using dynamic IP addresses it is recommended to use digitial certificates for authentication and not pre-shared keys. This allows Main mode to be used with the identity being established from the details in the certificate. Authentication Methods One of the parameters exchanged as part of IKE Phase 1 is the authentication method. The most common methods used are pre-shared key and digital signatures. Pre-Shared Key Authentication In this method both peers must know a shared secret in advance which is communicated via an out-of-bands medium (such as courier or telephone call between the security engineers). Due to the simplicity by which the keys can be exchanged it is very widely used. They keys used by the Diffie-Hellman exchange are derived from this pre-shared key. As mentioned above, when pre-shared keys are used and the VPN peers do not have fixed IP addresses (such as in a remote access scenerio), Aggresive Mode is the only choice for this peers Virtual Private Networks 11

16 Digitial Signature Authentication Peers are able to be authenticated with public key signaturues (either DSA or RSA). The Public Keys are normally obtained as Certificates and IKI allows for the exchange of them between intitiator and responder. The IKE Phase 1 process will exchange the public key (certificate) during the final 5th and 6th messages of a Main Mode exchange. The signers public key is used to decrypt and verify the messages being sent. Various details in the certificate can be used to identify the peer so it can be used in situations involving dynamic IP addresses. However due to the complexity of needing to setup a Public Key Infrastructure (PKI) this is none used as oftern as it should be. For more information on setting up a PKI and Certificate Authority Infrastructure, refer to the PKI section of this journal IKE Phase 2 Operation Once the IKE Phase 1 SAs have been establihed, Phase 2 can begin. Phase 2 only provides a single method of operation, known as Quick Mode. Once completed the two peers are ready to pass traffic using either ESP or AH. As mentioned previous, a minimum of two IPSec SAs are required for two-way communication between IPSec peers. Quick mode uses 3 message exchanges. All of these exchanges are protected by IKE and therefore encrypted and authenticated using the same keys derived in Phase 1. The Quick Mode Process is as follows: 1. The initiator will send the ISAKMP header and IPSec SA payload (including proposals and transforms) that will be used for bulk data. A new nonce is also exchanged between the peers. Because multiple quick mode exchanges may be ongoing, a Message ID is included to distinquish each transaction. 2. The responder replied with the choosen proposal along with the ISAKMP header, nonce and hash 3. In the 3rd message the initiator authenticates with a further hash value. This is then validated to avoid the possibility of earlier packets being replayed. Perfect Forward Secrecy By default the IPSec Keys are derived from the same initial key which could lead to an attacker with knowledge of the initial key being able to calculate all the current and future keys until IKE renegotiates. When Perfect Forward Secrecy (PFS) is enabled, new DH public values will be exchanged and the resulting shared secret will be used to generate new key material. IPSec Packet Processing The exact way in which IPSec packets are processed by a host or router is often down to a vendor chose to implement it so the above process should be seen as a top-level overview of the communication not exactly how vendors have designed their various solutions. RFC 2401 does describe a general approach that vendors should adopt to support interoperability that achieve the functional goals of IPSec. This model describes two databases that IPSec implementions with maintain: Security Policy Database (SPD) Security Association Database (SADB) 12 Chapter 1. Networking

17 Security Policy Database The SPD defines various selectors to identify packets that require IPSec Services: Destination IP address Source IP Address Name Data sensitivity level Transport layer protocols Source and Destination Ports One or more of these selectors will define the IP traffic encompassing the policy entry. Each entry will indicate whether traffic matching should be bypassed, discarded or subject to IPSec processing. If to be processed by IPSec the entries will include an SA (or SA bundle). Security Association Database Each entry in the SADB defines the parameters associated with one SA. Each an IPSec SA is created, the SADB is updated with all the parameters associated with it. The SA entry for an inbound packet is obtained by indexing the SADB with the destination IP in the outer IP header, SPI and IPSec security protocol (either ESP or AH). The SA entry for an outbound packet is obtained by a pointer to the SADB in the SPD. The SADB contains the following parameters: Sequence Number Sequence Number Overflow Anti-replay window SA lifetime Modes AH authentication algorithm ESP authentcation algorithm ESP encryption algorithm Path MTU IPSec Enhancements IKE Keepalives / DPD Idle Timeout Reverse Route Injection NAT-T Split Tunneling 1.1. Virtual Private Networks 13

18 IPSec and Fragmentation SSL VPNs SSL VPN Fundamentals SSL VPN Introduction Technology Overview Developed initially by Netscape SSL v1 (not released, v2, v3 SSL v3.0 served as basis of TLS IETF standard Cisco SSL VPN uses TLS SSL VPN Mode Clientless No need for client installation of the PC as long as they have a supported Web Browser Runs through the Browser Gateway can proxy requests from the browser to internal resources (HTTP_, HTTPS_, FTP_) Thin Client Designed for those non-web based applications that have static tcp port Uses Thin Client for supported protocols (such as Telnet, SSH_, RDP_, VNC_) Uses Java applets/activex Plugins so clients must have Java installed on their PC Popup blockers can also cause problem Arbitary ports can be supported through the use of smart forwarding Thick Client Requires installation of software on PC Not suitable for non-managed devices Requires Java/ActiveX installed for installation Provides all functionality as if user was on the LAN (assuming permitted over the VPN) Policies can be managed centrally 14 Chapter 1. Networking

19 SSL VPN Connection Process # Client initiated connection to server and requests a secure connection # Client provides a list of supported encryption/integrity algorithms (Cipher suite) # TLS server replies with a cipher/hash function it also supports # Server also sends back it s identity in the form of a digital certificate that should be provided from a trusted CA of the client. The servers public encryption key is also sent. # Client confirms validity of certificate and generates a session key # Client encrypts session key with the services public key and sends it to server # Server decrypts session key and begins encrypted session Terms Used SSL/TLS Can operate in the following modes: Clientless Thin Client Thick/Fat Client (TLS/DTLS) DTLS Old Pages Vendor VPN Implementations Cisco VPN Implementations Cisco IKEv1 Cisco IOS IKEv1 VPN Configuration Examples The following configurations will be demonstrated: Cisco IOS IKEv1 VPN Legacy Crypto Map with Pre-shared Keys In this section we will configure a pair of Cisco IOS routers to communicate over IPSec using IKEv1 using the older crypto map style of config and pre-shared key authentication It is assumed that the router already has basic IP connectivity to the public WAN and all private interfaces are configured. The default route is also assumed to be via the public WAN. 1. Define the pre-shared key for the remote peer 2. Define the Phase 1 ISAKMP policy 3. Define the Phase 2 IPSec Proposal and set the VPN encapsulation method 4. Define the Encryption Domain for the traffic which should be sent over the VPN 5. Combine all the various settings into a crypto map 6. Apply the crypto map to the public WAN interface 1.1. Virtual Private Networks 15

20 Configuration Steps Step 1: Define the pre-shared keys crypto isakmp key <psk> address <ip-of-peer> Step 2: Define the Phase 1 ISAKMP policy crypto isakmp policy <priority-number> encryption <encryption-algorithm> hash <integrity-algorithm> group <dh-group> lifetime <seconds> authentication pre-share Step 3: Define the Phase 2 IPSec Proposal crypto ipsec transform-set <ts-name> <encryption-algorithm> <hashing-algorithm> mode tunnel Step 4: Define the Encryption Domain To define the traffic to be encrypted an ACL needs to be created. Each entry in this access list will create a new Phase 2 Security Association which will take up resources on the VPN gateways. Where it is possible to do so summarisation of networks should be done and also avoid the use of per-host ACE s or those specifying individual ports and protocols (interface ACLS should be used for that purpose) access-list <acl-id-or-name> permit <local-net> <local-wildcard> <remote-net> <remote- wildcard> Step 5: Define the crypto map crypto map <cm-name> <seq-number> ipsec-isakmp match address <acl-id-or-name> set transform-set <ts-name> set security-association lifetime seconds <seconds> set peer <ip-of-peer> Step 6: Bind the Crypto Map to the receiving interface interface <type><slot/num> crypto map <cm-name> 16 Chapter 1. Networking

21 Complete example The example below is based of the below topology: Todo Insert topology image On the VPN Hub configure the following: crypto isakmp key mysecretkey address crypto isakmp policy 10 encryption aes hash sha lifetime group 14 authentication pre-share crypto ipsec transform-set ESP-AES128-SHA1 esp-aes 128 esp-sha-hmac mode tunnel ip access-list extended EACL-R1-TO-R2 permit ip crypto map CM-PUBLIC-WAN 10 ipsec-isakmp match address EACL-R1-TO-R2 set peer set transform-set ESP-AES128-SHA1 set security-association lifetime seconds interface FastEthernet0/0 crypto map CM-PUBLIC-WAN On the VPN Spoke configure the following: crypto isakmp key mysecretkey address crypto isakmp policy 10 encryption aes hash sha lifetime group 14 authentication pre-share crypto ipsec transform-set ESP-AES128-SHA1 esp-aes 128 esp-sha-hmac mode tunnel ip access-list extended EACL-R2-TO-R1 permit ip crypto map CM-PUBLIC-WAN 10 ipsec-isakmp match address EACL-R2-TO-R1 set peer set transform-set ESP-AES128-SHA1 set security-association lifetime seconds Virtual Private Networks 17

22 interface FastEthernet0/0 crypto map CM-PUBLIC-WAN Verification Once the VPN configuration has been applied, it will likely be necesary to generate some traffic which matches the encryption domain in order for the vpn establishment to start. In this example we have a loopback interface configured on both the hub ( ) and spoke ( ) so initiating a ping between these hosts should be sufficient. Because the Hub could be busy with dealing with other VPNs, lets does this on the spoke instead as follows: ping source The first few pings are likely to fail whilst the VPN is coming up but after that they should reply without issue. If the pings are replying we can probably assume that the VPN is up but how do we know for sure. Firstly lets check if the Phase 1 SA is up: show crypto isakmp sa detail The output should be similar to that below: C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap ACTIVE aes sha psk 14 23:59:53 If the status is showing a ACTIVE that is good as it means the VPN is believed to be stable and no further action is being taken. If is saying anything else it could indicate the VPN is having issues or that it is renegotiating (such as during a rekey after the lifetime has expired). We can also see that the Phase 1 properties have negotiated to what we configured. Assuming all is well, lets check that packets are being successfully encrypted and decrypted as follows: show crypto ipsec sa peer And the output should then be as follows: interface: FastEthernet0/0 Crypto map tag: CM-PUBLIC-WAN, local addr protected vrf: (none) local ident (addr/mask/prot/port): ( / /0/0) remote ident (addr/mask/prot/port): ( / /0/0) current_peer port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9 #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: , remote crypto endpt.: path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0 current outbound spi: 0xA464B844( ) 18 Chapter 1. Networking

23 PFS (Y/N): N, DH group: none inbound esp sas: spi: 0xAA697053( ) transform: esp-aes esp-sha-hmac, in use settings ={Tunnel, } conn id: 5, flow_id: 5, sibling_flags , crypto map: CM-PUBLIC-WAN sa timing: remaining key lifetime (k/sec): ( /28771) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE) outbound esp sas: spi: 0xA464B844( ) transform: esp-aes esp-sha-hmac, in use settings ={Tunnel, } conn id: 6, flow_id: 6, sibling_flags , crypto map: CM-PUBLIC-WAN sa timing: remaining key lifetime (k/sec): ( /28771) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE) The key information here, is whether packets are being encrypted and decrypted. If they are all is well and no futher action should be necessary. Other details that can be found out are whether the correct encryption and hashing is in place, whether PFS is being used, if reply detection is enabled and finally the remaining lifetime of the IPSec SA. The SPI s shown for both the inbound and outbound direct can be useful when performing packet captures as part of troubleshooting as they are not encrypted so can be used to identify a given VPN connection where possible a few are coming from the same IP address (e.g. with multiple ACE entries in the encryption domain) Troubleshooting Problem: ISAKMP SA state reports MM_KEY_EXCH and remote peer reports %CRYPTO-4- IKMP_BAD_MESSAGE: IKE message from <ip> failed its sanity check or is malformed Solution: Verify that the pre-shared key is configured correctly on both peers. Problem: Report peer reports phase 1 SA policy not acceptable! and local peer does not establish an ISAKMP SA. Solution: Verify that both peers have a matchin Phase 1 Policy, encryption, hashing and DH group need to be the same on at least one policy. Cisco IOS IKEv1 VPN with Static VTI with Pre-shared Keys In this section we will configure a pair of routers to communicate over a statically configured VTI using GRE over IPSec. This is useful in situations where you need to carry non-ip traffic through IPSEC. It is assumed that the router already have basic IP connectivity and WAN routing is in place. After the IPSec tunnel is configured working we will also setup dynamic routing through the tunnel Virtual Private Networks 19

24 Configuration Steps 1. Configure the PSK Keyring 2. Configure the ISAKMP Policy 3. Configure the ISAKMP Profile 4. Configure the IPSec Proposal 5. Configure the IPSec Profile 6. Configure the VTI tunnel using GRE over IPSec encapsulation 7. Configure routing via the tunnel Step 1: Define the PSK Keyring crypto keyring <keyring-name> pre-shared-key address <ip> key <psk> Step 1: Confifigure the ISAKMP Policy crypto isakmp policy <priority-number> authentication pre-shared encryption <encryption-algorithm> hash <integrity-algorithm> group <dh-group> lifetime <seconds> Step 3: Configure the ISAKMP Profile crypto isakmp profile <isakmp-profile-name> match identity address <ip> keyring <keyring-name> Step 4: Configure the IPSec Transform Set crypto ipsec transform-set <ts-name> <encryption-algorithm> <integrity-algorihm> mode transport Step 5: Configure the IPSec Profile crypto ipsec profile <ipsec-profile-name> set transform-set <ts-name> set security-association lifetime seconds <seconds> set isakmp-profile <isakmp-profile-name> 20 Chapter 1. Networking

25 Step 6: Configure the VTI interface interface Tunnel <id> tunnel mode gre ip tunnel source <wan-interface> tunnel destination <remote-peer-ip> tunnel protection profile ipsec <ipsec-profile-name> ip address <ip> <mask> no shutdown Step 6a: Configure routing (EIGRP) router eigrp <as-number> no auto-summary network <tunnel-subnet> <tunnel-mask> nework <lan-subnet> <lan-mask> Step 6a: Configure routing (EIGRP) router ospf <process-id> interface tunnel <id> ip ospf <process-id> area <area-id> ip ospf network point-to-point Complete Example The hub could be configured as follows: crypto keyring VTI-KEYRING pre-shared-key address key mysecretkey crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime crypto isakmp profile VTI-ISAKMP-PROF match identity address keyring VTI-KEYRING crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode transport crypto ipsec profile VTI-IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds set isakmp-profile VTI-ISAKMP-PROF set pfs group Virtual Private Networks 21

26 interface Tunnel 12 tunnel mode gre ip tunnel source FastEthernet0/0 tunnel destination tunnel protection ipsec profile VTI-IPSEC-PROF ip address no shutdown router eigrp 10 no auto-summary network network The spoke could be configured as follows crypto keyring VTI-KEYRING pre-shared-key address key mysecretkey crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime crypto isakmp profile VTI-ISAKMP-PROF match identity address keyring VTI-KEYRING crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode transport crypto ipsec profile VTI-IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds set isakmp-profile VTI-ISAKMP-PROF set pfs group2 interface Tunnel 12 tunnel mode gre ip tunnel source FastEthernet0/0 tunnel destination tunnel protection ipsec profile VTI-IPSEC-PROF ip address no shutdown router eigrp 10 no auto-summary network network Cisco IOS IKEv1 VPN with Dynamic VTI with Pre-shared Keys In this section we will configure a hub router that is able to offer VPN tunnels to a unknown number of dynamic VPN peers 22 Chapter 1. Networking

27 This is useful where you may need to rapidly deploy a varied number of sites and do not want to have to reconfigure the hub router everytime a new site is activated. The configuration we will be putting in place is suitable when the remote peers are using dynamic IP addressing but note that as we are using pre-shared key authentication the same key will be accepted from any IP address. This is not as secure as it could be and in a production deployment the use of digital signatures should be considerd. It is assumed that the router already have basic IP connectivity and WAN routing is in place. After the IPSec tunnel is configured working we will also setup dynamic routing through the tunnel. Configuration Steps On all devices: #. Configure a loopback to use a tunnel IP #. Configure the Keyring #. Configure the ISAKMP Policy #. Configure the ISAKMP Profile #. Configure the IPSec Proposal #. Configure the IPSec Profile #. Configure dynamic routing On the Hub: #. Configure the tunnel interface template On the Spokes: #. Configure a static tunnel interface Step 1: Define the Loopback Interface interface loopback <id> ip address <ip> Step 1: Define the PSK Keyring For the hub it s necessary to define a wildcard PSK if the spokes will be using dynamic IP addresses. If they will be static they can be defined individually but that would loose some of the flexibility of the solution. crypto keyring <keyring-name>! note the use of a wildcard key, this is used by any connecting peer pre-shared-key address key <psk> On the spokes the PSK can be defined with just the Hubs IP:.. code-block:: none crypto keyring <keyring-name> pre-shared-key address <hub-ip> key <psk> Step 1: Configure the ISAKMP Policy crypto isakmp policy <priority-number> authentication pre-shared encryption <encryption-algorithm> hash <integrity-algorithm> group <dh-group> lifetime <seconds> 1.1. Virtual Private Networks 23

28 Step 3: Configure the ISAKMP Profile crypto isakmp profile <isakmp-profile-name> match identity address keyring <keyring-name> virtual-template <template-id> Step 4: Configure the IPSec Transform Set crypto ipsec transform-set <ts-name> <encryption-algorithm> <integrity-algorihm> mode tunnel Step 5: Configure the IPSec Profile crypto ipsec profile <ipsec-profile-name> set transform-set <ts-name> set security-association lifetime seconds <seconds> set isakmp-profile <isakmp-profile-name> Step 6: Define the tunnel interfaces On the Hub we will configure a template that will be cloned each time a client connects. interface virtual-template <template-id> type tunnel ip unnumbered loopback <id> tunnel mode ipsec ip tunnel destination dynamic tunnel source <wan-interface> tunnel protection ipsec profile <ipsec-profile-name> On the Spokes we can configure a nubmer tunnel interface: interface Tunnel <id> ip unnumbered loopback <id> tunnel mode ipsec ip tunnel destination <hub-ip> tunnel source <wan-interface> tunnel protection ipsec profile <ipsec-profile-name> Complete Example The Hub config could be performed as follows: interface loopback 0 ip address crypto keyring DVTI-KEYRING pre-shared-key address key mysecretkey 24 Chapter 1. Networking

29 crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime crypto isakmp profile DVTI-ISAKMP-PROF match identity address keyring DVTI-KEYRING virtual-template 1 crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode tunnel crypto ipsec profile IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds set isakmp-profile DVTI-ISAKMP-PROF interface virtual-template 1 type tunnel ip unnumbered loopback0 tunnel mode ipsec ipv4 tunnel destination dynamic tunnel source FastEthernet0/0 tunnel protection ipsec profile IPSEC-PROF router eigrp 10 no auto-summary network network The Spokes could then be configured as follows: interface loopback 0 ip address crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime crypto keyring DVTI-KEYRING pre-shared-key address key mysecretkey crypto isakmp profile DVTI-ISAKMP-PROF match identity address keyring DVTI-KEYRING crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode tunnel crypto ipsec profile IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds set isakmp-profile DVTI-ISAKMP-PROF 1.1. Virtual Private Networks 25

30 interface tunnel 12 ip unnumbered loopback 0 tunnel mode ipsec ipv4 tunnel source FastEthernet0/0 tunnel destination tunnel protection ipsec profile IPSEC-PROF router eigrp 10 no auto-summary network network When ever a new spoke needs to be deployed the same config as above can be used, just change the following: 1. Loopback IP 2. Subnets advertised by routing protocol Static VTI Based IKEv1 VPN Dynamic VTI Based IKEv1 VPN Software-Based Remote Access IKEv1 VPN (Legacy IPSec Client) Hardware-Based Remote Access IKEv1 VPN (EasyVPN Client) Cisco ASA IKEv1 VPN Configuration Examples The following configurations will be demonstrated: Cisco ASA IKEv1 VPN Configuration with Pre-Shared Keys Example Introduction In this example we ll configure a Cisco ASA to talk with a remote peer using IKEv1 with symmetric pre-shared keys. Configuration Steps 1. Define the Encryption Domain 2. Specify the Phase 1 Policy 3. Specify the Phase 2 Proposal 4. Define the connection profile 5. Configure the Crypto Map 6. Bind the Crypto Map to the appropriate interface 7. Enable IKEv1 on the appropriate interface 26 Chapter 1. Networking