Virtual Private Network - VPN

VPN

Security = encryption and integrity

Encryption user keys (aes / 3des)

Integrity uses hash (cisoc support sha and md5)

Hash > encrypt ---------------------- decrypt > hash

Entire security lies in creating and exchanging key.

1.   Create a public shared key and send it to other party, this method is most vulnerable.

2.   Use static key, but static key can be cracked over a period of time.

3.   Use key exchange algorithm

a.   Firewall creates two key DH public key and DH private key.

Public key used for encrypting data and private key for decrypting data.

b.   Public key is exchanged

c.    Authenticate two firewall with each other using pres-hare key.

 Take hash of preshare key

Encrypt is using public key send it to other side

Decrypt it using private key

Take hash on other side and compare the hashes

Generate share secret key

Encrypt it and send it on other side.

Decrypt share –secrete key on other side

Main objective is using key to encrypt / decrypt. The key is exchanged on ISAMMP

***************************

How HTTPs works

1.      Client make tcp connection on destination port 443

2.      Ssl handshake process starts once tcp connection is established

a.      Browser send the CLIENT HELLO message

                                                              i.      It contains information like

1.      Highest version of SSL supported by browser

2.      Compression method that it supports

3.      Suite of cipher it can user for encryption

4.      And random data which can later use when generating symmetric key for session.

b.      Server response with SERVER HELLO

It contains

1.      SSL version used for session

2.      Cipher and compression method that will be used

3.      Session id for ssl session

4.      Random data used for key generation process.

c.       Server then send Digital certificate singed by CA

It serves for two purposes

1.      It contain public key so that browser can use key to encrypt sent to server it can optionally send chain of certificate beginning with certificate of authority that issued the server certificate.

2.      It established the identity of the server from which the web page is coming.

d.      Server sends SERVER HELLO DONE message

e.      Browser respond by sending CERTIFICATE VERIFY message that it has verified the certificate

f.        Browser then sends CHANGE CIPHER SPEC command to server telling it now on data send to server will be encrypted.

g.      After that browser send FINISHED MESSAGE. This contains digest of message exchanged between browser and server till now. This is done to ensure that none of the information exchanged earlier is tampered during transit.

h.      Server responds with CHANGE CIPHER SPEC message hinting browser that now on data send by server will be encrypted.

i.        Server sends FINISHED MESSAGE containing digest of all message between browser and server.

j.        Now we consider SSL handshake to be complete

3.      Browser generate symmetric secret key just to be used for this ssl session. It encrypt generated key using public key of the serve and send it across to the server. This key remains secret with browser and server.

Note: Reason for using symmetric key is encryption and decryption using symmetric key is lighter then asymmetric key. 

**********************

Types of VPN

·         IPSec – operate at network layer (RFC 2401)

o   Site-to-Site / LAN-to-LAN (L2L)

o   Remote access

·         SSL (WebVPN)

·         PPTP (created by Microsoft) – operate in data link layer

·         L2TP – ietf combined pptp and l2f – operate in data link layer

·         L2F (Layer 2 forwarding protocol)  - operate in data link layer

IPSec VPN

IPSec Protocol

·         IPsec is a set of protocols developed by the IETF to support secure exchange of packets at the IP layer.

·         IPsec includes protocols for establishing mutual authentication between peers at the beginning of the session and negotiation of cryptographic keys to be used during the session.

·          IPsec is available for both IPv4 and IPv6 and has been deployed widely to implement Virtual Private Networks (VPNs).

Fig 1 Interrelationship of IPSec core documents

The Architecture document covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology.

·         The ESP Protocol and AH Protocol documents cover the packet format and general issues regarding the respective protocols.

·         The Encryption Algorithms document is the set of documents describing how various encryption algorithms are used for ESP.

·         The Authentication Algorithm is the set of documents describing how various authentication algorithms are used for both ESP and AH.

·         The DOI document contains values needed for the other documents to relate to each other. This includes for example encryption algorithms, authentication algorithms, and operational parameters.

·         The Key Management Documents are the documents describing the IETF standards-track key management schemes (ISAKMP/Oakley, IKE).

RFC 4301 “the ip security architecture”

-          Defines the original IPsec architecture and elements common to both AH and ESP

IPSec mode:
Transport mode

·         Default IPSec mode

·         Only IP payload is encrypted 

Note:
IP Payload = tcp segments = tcp header + tcp segment data
                   = udp segment
                   = ICMP message

·         Protected through AH / ESP header

Tunnel mode

·         It is more secure and encrypts both the header and the payload.

IPSec Protocol:

AH (Authentication Header)

·         Provide authentication, integrity & anti-reply protection

·         It does not provide confidentiality / no encryption

·         Data is readable but protected from modification

·         AH is identified in the IP header with the IP protocol ID of 51, AH can be used alone or combined with the esp protocol, in this case AH header is inserted before esp.

·         AH is a format protocol defined in RFC 2402

AH in transport mode:

·         AH header is inserted between ip header & ip datagram

·         In Original ip header next header field value is changed to 51

·         In Ah header next protocol text protocol reference to tcp

 

AH in tunnel mode:

·         In tunnel mode the IPv4 datagram is encapsulated into a new IPv4 datagram that includes the AH header.

·         The AH header’s use the value 4 which means IPv4 in its next header.

·         Everything is authenticated except – DSCP, ToS, TTL, Check sum

ESP (Encapsulation security payload)

·         Provides confidentiality + authentication + integrity + anti-reply

·         Protocol ID 50

·         ESP is a format protocol defined in RFC 2406

·         ESP supports the use of symmetric encryption algorithms, including DES, 3DES, and AES, for confidentiality and the use of MD5 HMAC and SHA1 HMAC for data authentication and integrity.

ESP has several fields that are the same as those used in AH, but packages its fields in a very different way. Instead of having just a header, it divides its fields into three components:

1.       ESP Header: This contains two fields, the SPI and Sequence Number, and comes before the encrypted data. Its placement depends on whether ESP is used in transport mode or tunnel mode.

2.       ESP Trailer: This section is placed after the encrypted data. It contains padding that is used to align the encrypted data, through a Padding and Pad Length field. Interestingly, it also contains the Next Header field for ESP.

3.       ESP Authentication Data: This field contains an Integrity Check Value (ICV), computed in a manner similar to how the AH protocol works, for when ESP's optional authentication feature is used.

There are two reasons why these fields are broken into pieces like this.

1.       The first is that some encryption algorithms require the data to be encrypted to have a certain block size, and so padding must appear after the data and not before it. That's why padding appears in the ESP Trailer.

2.       The second is that the ESP Authentication Data appears separately because it is used to authenticate the rest of the encrypted datagram after encryption. This means it cannot appear in the ESP Header or ESP Trailer.

Note:

1.       ESP support digital signature but exclude outer IP header, whereas AH includes IP header thus not support NAT.

2.       ESP & AH is layer 3 protocol thus not supported by PAT-device / Statefull firewall.

3.       PAT issue can be fixed for ESP by using NAT  TRAVERSAL or IPSec over TCP (Cisco proprietary)

How IPSec works

An IPSec tunnel establishment process can be broken down into five main steps:

1.       Tunnel initiation – triggered by interesting traffic, it start IKE process

2.       IKE Phase 1

3.       IKE Phase 2 –negotiate the parameters and key material to established two unidirectional IPSec SAs for incoming and outgoing traffic (2 DATA connection).

4.       Data Transfer

5.       Tunnel termination

ISAKMP identity – used to identify remote peer.

·         By ip address

·         By name (FQDN)

The ISAKMP and IKE protocol define how to establish on IPSec session between two peers. Three connections (1 Management and 2 data connections) make up the session. The connection are built across two phase.

In phase I –

·         Negotiate the parameters and key material required to establish ISAKMP SA (1 management connection).

·         ISAKMP SA is used to protect future IKE exchanges and to set up a secure channel for negotiating IPSec SAs in IKE phase 2.

·          Purpose is to establish secure authenticated communication channel by using the Diffie-Hellman key exchange algorithm to generate a shared secret key to encrypt IKE communication. The authentication can be performed using either pre-share key (shared secret), digital signatures or public key encryption as described by RFS 2409.

IKE phase I operate in either Main Mode or Aggressive mode.

Main mode: Has 3 two-way exchanges between the initiator and the receiver. And it protect the identity of the peer.

·         First exchange: The algorithms and hashes used to secure the IKE communications are agreed upon in matching ISAKMP SAs in each peer.

·         Second exchange: Uses a Diffie-Hellman exchange to generate shared secret keying material used to generate shared secret keys and to pass nonces (In security engineering, a nonce is an arbitrary number used only once in a cryptographic communication.) numbers sent to the other party and then signed and returned to prove their identity.

·         Third exchange: Verifies the other side’s identity (the identity value is an IP address, an FQDN, an email address, a DNS or a KEY ID form in encrypted form). The main outcome of main mode is matching ISAKMP SAs between peers to provide a protected pipe for subsequent protected ISAKMP exchanges between the IKE peers. The ISAKMP SA specifies values for the IKE exchange: the authentication method used, the encryption and hash algorithms, the Diffie-Hellman group used, the lifetime of the ISAKMP SA in seconds or kilobytes, and the shared secret key values for the encryption algorithms. The ISAKMP SA in each peer is bi-directional.

Aggressive mode:
Aggressive Mode has fewer exchanges with fewer packets. On the first exchange, almost everything is squeezed into the proposed ISAKMP SA values: the Diffie-Hellman public key (a nonce that the other party signs) and an identity packet, which can be used to verify identity via a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides have exchanged information before there’s a secure channel. Therefore, it’s possible to sniff the wire and discover who formed the new SA. However, it is faster than main mode

Management connection is encapsulated in UDP port 500

We can choose three authentication methods for phase I

1.       Pre-shared keys

2.       Certificate (RSA signatures)

3.       Cryptographic keys (CRACK) used with mobile / smart phones.

Default policy
Authentication : pre-share

Encryption : 3DES

DH :2

Hash : SHA HMAC

Life time : 1 day (86400 sec)

If NAT is used then IPSec management and data connection are established , but data can’t be  successfully transmitted between two peers.

To use PAT with ESP there are two solutions.

NAT  traversal / NAT transparency / NAT –T

·         It inserts UDP header between IP header and ESP header.

·         UDP PORT 4500

·         Discovery phase takes place during phase I to determine if two peers support NAT. UDP header is inserted based on need , it add 8 bytes of overhead.

·         NAT-T is globally enabled by default

·         It sends keepalives across data connection to ensure NAT / Statefull firewall don’t remove any idea connection . Default period 20 sec (range 10 – 3600 sec)

·         RFC 3947 defines the negotiation during the Internet key exchange (IKE) phase and RFC 3948 defines the UDP encapsulation.

IPSec over TCP

There are two problems with NAT-T

·         It uses UDP, typically has much smaller idle timeout than tcp connections for NAT / Statefull FW.

·         Fixed port 4500

Cisco created proprietary encapsulation method called IPSec over TCP, it insert tcp 20 bytes header between outer IP and ESP header, we can control port (upto 10) by default port 1000 is used. NAT – T / IPSec over TCP are commonly used for remote access connections, where intermediate FW / NAT devices are more likely to be encounter.

Dead Peer Detection (DPD) is used to monitor the peer and quickly detect when it gets unreachable. It works by exchanging probe packets, and if the peer does not answer for some time, the security associations are killed. DPD is documented by RFC 3706.

 XAUTH, Mode config and Hybrid authentication are optional extensions of the IKE phase 1 described in RFC drafts.

 Extended Authentication (XAUTH) provides additional user authentication by prompting the user for a username and password.

 Mode config is used to deliver parameters such as IP address and DNS address to the client.

Hybrid authentication makes the IKE phase 1 asymmetric: the VPN IPsec server authenticates to the IPsec clients by using a certificate, and the client does not authenticate in IKE phase 1. This extension is usually used with XAUTH to provide a high security level.

IKE Phase 2

The purpose of IKE phase 2 is to negotiate IPsec SAs (Data connection) to set up the IPsec tunnel. The data connection is unidirectional (therefore two data connection) are protected with either the AH /ESP. IKE phase 2 performs the following functions:

 •Negotiates IPsec SA parameters protected by an existing ISAKMP SA.

 •Establishes IPsec security associations.

 •Periodically renegotiates IPsec SAs to ensure security.

 •Optionally performs an additional Diffie-Hellman exchange.

IKE phase 2 has one mode called quick mode. Quick mode occurs after IKE has established the secure tunnel in IKE phase 1. It negotiates a shared IPsec policy, derives shared secret keying material used for the IPsec security algorithms, and establishes IPsec SAs. Quick mode exchanges nonces that provide replay protection. The nonces are used to generate new shared secret key material and prevent replay attacks from generating bogus SAs.

Quick mode is also used to renegotiate a new IPsec SA when the IPsec SA lifetime expires. Base quick mode is used to refresh the keying material used to create the shared secret key based on the keying material derived from the Diffie-Hellman exchange in IKE phase 1.

If perfect forward secrecy (PFS) is specified in the IPsec policy, a new Diffie-Hellman exchange is performed with each quick mode, providing keying material that has greater entropy (key material life) and thereby greater resistance to cryptographic attacks. Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use and exacting a performance cost.

When the IPsec SAs terminate, the keys are also discarded. When subsequent IPsec SAs are needed for a flow, IKE performs a new IKE phase 2 and, if necessary, a new IKE phase 1 negotiation. A successful negotiation results in new IPsec SAs and new keys. New IPsec SAs can be established before the existing SAs expire, so that a given flow can continue uninterrupted.

What is PFS?

PFS ensures that the same key will not be generated again, so forces a new diffie-hellman key exchange. This would ensure if a hacker\criminal wants to compromise a private key, he would be able to access data in transit which protected by that key and not any future data, as future data will not be associated with that compromised key.

Both sides of VPN should support PFS in order for PFS to work. Therefore using PFS provides a more secure VPN connection.

Resolution

The crypto map set pfs command sets IPSec to ask for Perfect Forward Secrecy (PFS) when new security associations are requested for this crypto map entry. Alternatively, it asks that IPSec requires PFS when requests are received for new security associations.

To specify that IPSec not request PFS, issue the no crypto map set pfs command. This command is only available for ipsec-isakmp crypto map entries and dynamic crypto map entries.

Note: By default, PFS is not requested.

With PFS, every time a new security association is negotiated, a new Diffie-Hellman exchange occurs, which requires additional processing time.

PFS adds another level of security because if one key is ever cracked by an attacker, only the data sent with that key is compromised. During negotiation, the no crypto map set pfs command causes IPSec to request PFS when new security associations are requested for the crypto map entry.

The default (group1) is sent if the set pfs statement does not specify a group. If the peer initiates the negotiation and the local configuration specifies PFS, the peer must perform a PFS exchange or the negotiation fails.

If the local configuration does not specify a group, a default of group1 is assumed and an offer of either group1 or group2 is accepted. If the local configuration specifies group2, that group must be part of the peer offer or the negotiation fails.

Note: Internet Key Exchange (IKE) negotiations with a remote peer can hang when a PIX Firewall has numerous tunnels that originate from the PIX and terminate on a single remote peer. This problem occurs when PFS is not enabled and the local peer asks for many simultaneous rekey requests. If this problem occurs, the IKE security association does not recover until it has timed out or until the clear [crypto] isakmp sa command is issued to manually clear it. PIX units configured with many tunnels to many peers, or many clients sharing the same tunnel, are not affected by this problem. If the configuration is affected, issue the crypto map mapname seqnum set pfs command to enable PFS.

CISCO ASA Introduction

The Cisco ASA provides advanced stateful  firewall and VPN concentrator functionality in once device, and for some models, integrated services modules such as IPS.

Features supported by ASA.

1.       Stateful firewall.

2.       VPN concentrator.

3.       IPS ( via module)

4.       Multiple security contexts ( similar to virtualized firewalls)

5.       Clustering ( combining multiples firewall into a single firewall)

6.       Layer 2 FW ( transparent mode) or Layer 3 FW (routed mode)

7.       Advanced inspection engines.

8.       VPN (IPsec / SSL / Clientless SSL.

ASA services module with the switch.

You can install the ASASM in the catalyst 6500 and Cisco 7600 series switches with Cisco IOS software on both the switch supervisor and the integrated MSFC.

Firewall Functional Overview.

Inside – Outside – DMZ (demilitarized zone)

Security Policy Overview.

Determines which traffic is allowed to pass through the firewall.

Permitting or Denying  Traffic with Access lists.

·         To limit traffic from inside to outside.

·         To allow traffic from outside to inside.

·         For transparent FW mode, you can apply an EtherType access list to allow non-IP traffic.

Applying NAT

·         Translation for private non routable address.

·         Hides real address.

·         Support overlapping IP address.

Protecting from IP fragments.

·         The ASA provides IP fragment protection. This feature performs full reassembly of all ICMP error messages and virtual reassembly of the remaining IP fragments that are routed through the ASA. Fragments that fail the security check are dropped and logged. Virtual reassembly cannot be disabled.

Using AAA for through traffic

·         You can require authentication and/or authorization for certain types of traffic, for example, for HTTP.The ASA also sends accounting information to a RADIUS or TACACS+ server.

Applying HTTP, HTTPS, or FTP filtering

·         Due to dynamic nature of the Internet configuring and managing web usage using ACL is not practical. ASA can be used in conjunction with separate server running one of the following Internet filtering products.

o   Websense Enterprise

o   Secure computing smartFilter.

Applying Application Inspection.

·         Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the ASA to do a deep packet inspection.

Sending traffic to the IPS module.

·         If your model supports the IPS module for intrusion prevention, then you can send traffic to the module for inspection. The IPS module monitors and performs real-time analysis of network traffic by looking for anomalies and misuse based on an extensive, embedded signature library. When the system detects unauthorized activity, it can terminate the specific connection, permanently block the attacking host, log the incident, and send an alert to the device manager. Other legitimate connections continue to operate independently without interruption.

Sending traffic to the content security and control module

·         If your model supports it, the CSC SSM provides protection against viruses, spyware, spam, and other unwanted traffic. It accomplishes this by scanning the FTP, HTTP, POP3, and SMTP traffic that you configure the ASA to send to it.

Applying QoS policies.

·         Some network traffic, such as voice and streaming video, cannot tolerate long latency times. QoS is a network feature that lets you give priority to these types of traffic. QoS refers to the capability of a network to provide better service to selected network traffic.

Applying connection limited and tcp normalization.

·         You can limit TCP and UDP connections and embryonic connections. Limiting the number of connections and embryonic connections protects you from a DoS attack. The ASA uses the embryonic limit to trigger TCP Intercept, which protects inside systems from a DoS attack perpetrated by flooding an interface with TCP SYN packets. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination. TCP normalization is a feature consisting of advanced TCP connection settings designed to drop packets that do not appear normal.

Enabling threat detection

·         You can configure scanning threat detection and basic threat detection, and also how to use statistics to analyze threats. Basic threat detection detects activity that might be related to an attack, such as a DoS attack, and automatically sends a system log message. A typical scanning attack consists of a host that tests the accessibility of every IP address in a subnet (by scanning through many hosts in the subnet or sweeping through many ports in a host or subnet). The scanning threat detection feature determines when a host is performing a scan. Unlike IPS scan detection that is based on traffic signatures, the ASA scanning threat detection feature maintains an extensive database that contains host statistics that can be analyzed for scanning activity. The host database tracks suspicious activity such as connections with no return activity, access of closed service ports, vulnerable TCP behaviors such as non-random IPID, and many more behaviors. You can configure the ASA to send system log messages about an attacker or you can automatically shun the host.

Enabling the Botnet traffic filtere

·         Malware is malicious software that is installed on an unknowing host. Malware that attempts network activity such as sending private data (passwords, credit card numbers, key strokes, or proprietary data) can be detected by the Botnet Traffic Filter when the malware starts a connection to a known bad IP address. The Botnet Traffic Filter checks incoming and outgoing connections against a dynamic database of known bad domain names and IP addresses (the blacklist), and then logs any suspicious activity. When you see syslog messages about the malware activity, you can take steps to isolate and disinfect the host.

Configuring Cisco Unified Communications

·         The Cisco ASA 5500 series is a strategic platform to provide proxy functions for unified communications deployments. The purpose of a proxy is to terminate and reoriginate connections between a client and server. The proxy delivers a range of security functions such as traffic inspection, protocol conformance, and policy control to ensure security for the internal network. An increasingly popular function of a proxy is to terminate encrypted connections in order to apply security policies while maintaining confidentiality of connections.